And what’s beautiful is that the one right under has a comment “we don’t use thi…”
This code looks like so much fun to debug…
i like to imagine it says
we don’t use this, but if you delete it everything in this file breaks
Load bearing code
we don’t use this without first writing proper unit tests for our changes, integrating them with the regression tests, and thoroughly documenting our changes for the next developer that has to work on this
I’m an optimist, and it’s technically possible
Ok cool now write some unit tests for a 13,000 line function
🙃
There’s one I found today that just reads “this is a fucking abortion”
I don’t remember doing it, but it was almost certainly me.
I would legit love to refactor that bad boy and get >95% code coverage. Put me in, coach!
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.
Is the function called
is_even()?Here, I optimised it:
private function is_even(integer): integer = 2; return True;what unholy combination of programming languages is this
def is_even(num:int) -> bool: if x < 0: x = x * (-1) if x == 0: return True elif x == 1: return False elif x == 2: return True elif x == 3: return False elif x == 4: return True elif x == 5: return False elif x == 6: return True elif x == 7: return False # ...Yes, and it only returns, “I can’t even”
Holy mother of functions
I have a rule in my NVim
init.vimthat it gets room for three line number digits. If it goes over, the screen shifts uncomfortably as warning. That works for my current projects.imagine if the entire function is a single if-else statement which they kept adding onto, but could never refactor lest everything crashes down and burn.
I once worked on a project doing firmware that a lot of people have likely used (printer firmware for a big-name company). One of the more trafficked functions was something like 1500 lines of “if-elseif-elseif…” with something like 13 or 14 different cases.
It did end up getting refactored to something polymorphic and based on a configuration file to cut out any unnecessary steps, but it was like that for a while before I got there, and was like that for most of the year that I was part of the project.To be fair, I think massive “switchboards” can be relatively clean. The key is that each step contains little enough logic. 1500 lines of 13-14 cases means the average block was > 100 lines, and at that point I definitely agree that it should probably have been refactored a long time ago. Just splitting that into 13-14 smaller functions, and using the switchboard as a delegator could be completely fine.
You’re dredging up some bad memories 😅
Saw one once called something dangerously innocent like “run_validation” that turned out to be a 5K line hand built deserializer (no libraries used when then absolutely should have) with so many nested levels the editor put “expand this line?(2kb)” warnings at the end of most lines.
In the original author’s defence the garbage being deserialized was an Eldritch horror. We eventually moved to JSON.
4k+ nested if statements with comments.
that’s some PTSD right there. just leave that closed as long as you can
I have no memory of this place.
Those lines are mostly comments, right? Right?
Yeah, just comments… with chapters…
oh look, it’s the old codebase at my job
Legit, the company banned people from using
in their scripts because too many people were using it to hide massive amounts of slop code. Just giant fucking IF trees. Even though using it is hugely beneficial to keep things organized, especially if you use a lot of interfaces.get date switch case
One sheet of paper rule exists for a reason
I can smell it from here
It’s a private function and you weren’t invited. No need to look closer








