+ 1

How much complexity is good/overkill?

Lately I showed one of my beginner works to a friend who is a Java developer. He criticized a few things, one of them being that I don't have different files for functions, front-end and so on. From my perspective, this didn't appear necessary: Since the whole script was below 200 lines, what would be the benefit of several files which would necessitate a folder and so on? Also I recently watched a YouTube video where a developer showed examples of people writing a few dozen lines of class definition, although a simple function of a few lines using built-ins would have done the job just the same. Python is my first programming language, and since I am now trying to figure out the OOP stuff, I'd like to hear your opinions: How much complexity, modularization and objectification (that a word?) is optimal and how can I judge that from case to case?

2nd Jul 2018, 6:46 PM
HonFu
HonFu - avatar
7 odpowiedzi
+ 3
Dont listen to Java developers. Make a copy of the "Zen of Python" and put it under your pillow.
2nd Jul 2018, 7:01 PM
Qwertiony
Qwertiony - avatar
+ 3
Don't use OO programming for the sake of it in multi-paradigm languages. Beware that certain standards are expected of published, open source work (such as separate header files in C++). If you can _elegantly_ simplify it, do so. Always ensure code is readable and neat. Some portions may warrant separate functions and files purely so _you_ can _re-use_ them in projects to come. The _most_ important thing is logical modularity (Python is a poor language for this, but still): Every part of your program must do one thing, but do it well (Unix philosophy IIRC). However, a simple little script can be an exception (why Python, a scripting language, is not ideal as a learning aid here).
2nd Jul 2018, 7:08 PM
non
+ 2
Nonzyro, thanks for the broad overview about how you handle complexity! I see that I am not completely alone with the idea that you should use stuff when you need it, not just because it's available (or trendy). When I started to look into Python a few months ago, I knew nothing at all... thirty years earlier I had done a bit of very basic stuff with C64 Basic, and that's all. So when I started, I saw, oh, okay, there are no lines numbers and "goto"s, but there is for and while, so let's work with that. When I started to need a procedure more than just one time, I started to make functions - but only for the cases where it avoided writing stuff twice. Then I saw that I had a hard time understanding what I wrote a few weeks later, and that it actually helps to put program functions in functions generally, and keeping them somewhat clean. And that's basically where I am at now. So I suppose I'll just go on and let my sense of structure evolve as the scripts grow longer!
3rd Jul 2018, 11:30 AM
HonFu
HonFu - avatar
+ 1
Yeah, I read that, too, and it sounded like common sense to me. I remember the college days where some people structured their mini essay of 20 something pages with markers like 1.1.1., and I always wondered: What's the point of creating that sort of structure with that little content? Why not be honest and stick to just 1., 2. and 3.? Anyway, if a certain format or style is expected by the community, it probably won't help me to be a little rebel. ;-) Also there might be reasons I simply can't see yet...
2nd Jul 2018, 7:09 PM
HonFu
HonFu - avatar
+ 1
Nonzyro, yeah, that's exactly my thinking: I feel reluctant to make several files or define classes if it's not really necessary in the case at hand or doesn't simplify anything. So my question is (in order to avoid being ignorant and missing the good stuff when it's good), how I can identify the cases where a larger degree of fragmentation makes sense. I hope to understand where the 'certain expected standards' come from.
2nd Jul 2018, 7:22 PM
HonFu
HonFu - avatar
+ 1
Okay, well Java devs are forced to put everything in classes and even have classes for primitives nowadays. Java has different goals. So throw your friend's advice aside for when/if you learn Java. How to tell if I need to apply anything special to my single-file code. If yes to any, consider a breakup: - Is it large or could it grow large (count instructions, not lines)? - Is it complex? Is there lots of nesting more than 3 levels? - Do I have many blocks spanning more than an average screen height (16x Font, 720p screen)? How to break it up? - One piece of code does one job only, but does it well. - Functions _may_ have a file each _or_ collections of related functions may go in a single file. Example: math.py - Is a class needed? Do I need a complex datatype? Do I need it to have interfaces? - I suggest classes have their own files to make them easier to locate and use. You'll refine your own organisation the more code you write. Search "KISS coding" too for ideas.
2nd Jul 2018, 9:36 PM
non
+ 1
As to standards, they are defined usually by a language philosophy, the firm you work for, your team, the code you're contributing to, or _you_. I don't follow standards at all. I obey where needed. When in Rome... -- as they say. I break functions up into single files because in C it makes it easy to debug. I use collection headers to include entire collections of functions as I find it easy, but I'd never do that on a team. I use classes in C++ when I have to because I'm a C programmer and naturally avoid them. Mostly, procedural programming is quicker and easier. But then there comes a time when I think, "I need a class" as the solution. It's because of that I know I'm not just erroneously using classes. Remember that you'll realise on your own most of what feels right. I'm afraid only experience helps there.
2nd Jul 2018, 9:56 PM
non