When I was in my 101 comp sci classes, one of my professors would say, “A function is meant to do one thing. So if your function doesn’t fit on the monitor in it’s entirety, that is a good indication your function is probably too complicated and/or doing too many things. Either simplify it or break it down further.” And that’s a rule I usually try to live by with my professional work too. So, anyway… I want to see the 4000k monitor this guy is using.
also depth of blocks: if i’m more than 2 or 3 indents deep, it’s probably got a bit too much logic to it and those comments should be converted to a function name
The rule of thumb I use is how likely am I to reuse some part of this code in the future? Also readability. Sometimes I like to just wrap some code in functions to make the code look neater. Other considerations are how often will this function be called? The overhead of calling a function is tiny but if a program is used by millions, everyday for many years, it’s sort of like not littering a bit to make the code a bit more inline. It is kind of nice to be able to mostly see what a piece of code does in a glance other than when it’s just wasteful.
Concise readability is usually my goal. Like if I have 12+ lines of code with a loop and some nested conditionals, recursively digging into buried directories, that probably takes a bit of thought to parse. So it is probably is better to move that to a function with a descriptive name like, “size, depth = get_directory_size_and_depth(filepath)”, that way the function name itself serves as it’s own comment/documentation describing what’s being done and, if you don’t really care about how the size and depth is aggregated, it abstracts that process into one line of code in the calling function that the reader can instantly understand without parsing the whole process. That goes doubly so when the function is generic like get_directory_size_and_depth(filepath) would be, and can be put in its own shared utilities file.
If the alternative to changing into a new file is to search through a 40k lines file that has no structure, then I rather go to a new file. As my train of thoughts is interrupted by the size of the file.
And a good compiler is capable of a lot these days. However if you are working on low end hardware that has to perform good and fast then you should of course think about the compiler.
When I was in my 101 comp sci classes, one of my professors would say, “A function is meant to do one thing. So if your function doesn’t fit on the monitor in it’s entirety, that is a good indication your function is probably too complicated and/or doing too many things. Either simplify it or break it down further.” And that’s a rule I usually try to live by with my professional work too. So, anyway… I want to see the 4000k monitor this guy is using.
also depth of blocks: if i’m more than 2 or 3 indents deep, it’s probably got a bit too much logic to it and those comments should be converted to a function name
The rule of thumb I use is how likely am I to reuse some part of this code in the future? Also readability. Sometimes I like to just wrap some code in functions to make the code look neater. Other considerations are how often will this function be called? The overhead of calling a function is tiny but if a program is used by millions, everyday for many years, it’s sort of like not littering a bit to make the code a bit more inline. It is kind of nice to be able to mostly see what a piece of code does in a glance other than when it’s just wasteful.
Concise readability is usually my goal. Like if I have 12+ lines of code with a loop and some nested conditionals, recursively digging into buried directories, that probably takes a bit of thought to parse. So it is probably is better to move that to a function with a descriptive name like, “size, depth = get_directory_size_and_depth(filepath)”, that way the function name itself serves as it’s own comment/documentation describing what’s being done and, if you don’t really care about how the size and depth is aggregated, it abstracts that process into one line of code in the calling function that the reader can instantly understand without parsing the whole process. That goes doubly so when the function is generic like get_directory_size_and_depth(filepath) would be, and can be put in its own shared utilities file.
I personally go by the monocre that if it’s something important, it’d be all on one file as not to lose the train of thought when debugging it.
As jumping around between files
tends to break up thought lines
also, the compiler likes it better when there’s less layers
The compiler can get fucked
I said function, not file. You can have 40 functions in one file.
oh yeah, that’s fair.
Are those your arguments?
Train of thought is subjective
And the compiler doesn’t care
Yeah? If something is important being able to have it all on one file is the best way to ensure you get the behaviour you want.
Having to file-hop is generally a strain on mental resources and it breaks the linearity of the project, ofuscating initial reads.
And yes, the compiler does care, there are no 0-cost abstractions.
Yesnt.
If the alternative to changing into a new file is to search through a 40k lines file that has no structure, then I rather go to a new file. As my train of thoughts is interrupted by the size of the file.
And a good compiler is capable of a lot these days. However if you are working on low end hardware that has to perform good and fast then you should of course think about the compiler.
In 99% of software that isn’t the case though