Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
With the short variable you probably also get shadowing. That's super fun in a new code base.
Or another favourite of mine: The first time I had to edit a perl script at work someone had used a scalar and a hash with the same name. Took me a while to realize that scalars, arrays, and hashes have separate namespaces, and the two things with seemingly the same name were unrelated.
The link is a proxied image link for some reason.
Oh, it's only the files that have over 2k lines of code? Hell, I'll take that over what I'm dealing with now. I've got multiple FUNCTIONS that are over 2k lines. >:(
Yeah, I dont see a big problem with files over 2000 lines in some cases, as long as things remain well writrej, organized, abstractd.
One piece of garbage that I'll never touch again hae most functions this size. One was 50,000 lines! Hundreds.of lines of if/else, half of the functions passed the same 60 arguments because he didn't understand classes or even dictionaries, etc etc. And was used heavily.
every programmer I've seen who says their code is self documenting writes dogshit code
Ngl that's like baby levels of nasty code. The real nasty shit is the stuff with pointless abstractions and call chains that make you question your sanity. Stuff that looks like it's only purpose was to burn the clock and show off a niche language feature. Or worse than that even is when the project you inherit has decade old dependencies that have all been forked and patched by the old team
If all I had to worry about was organization and naming I'd be over the moon
Git commits with message saying “pushing changes” and there are over 50 files with unrelated code in it.
"fixed issue"
"Fix for critical issue."
Followed by an equally large set of files in a commit with just the message:
"Fixup"
And then the actual fix turns out to be mixed in with "Start sprint 57 - AutoConfiguration Refactor" which follows "Fixup"
Former coworkers: “oh, these two lines are the same in function x and function y. TIME TO ABSTRACT”
That's what agentic AI is for! Your OS will figure out by itself what you are doing and weave together a shambolic rococo digital house of cards that will be not just undocumented but utterly incomprehensible.
It's fine, just get a 5GHz CPU with 48 cores, 1TB of DDR5 HBM super RAM, and maybe a few petabytes of storage (in the cloud in a flatpack Docker that runs on a VM), so that you can finally make that button blue.
Shut up and take my venture capital money! And maybe 2/3 of the whole market cap in stock options! /s
Fucken right, get your agentic AI to get in touch with my agentic AI (with wire transfer deets)
Even worse than there being no comments: the code is extensively commented, but its function has drifted from what the comments describe to the point where they are actively misleading.
There are no comments in the code
At my last job, I was assigned to a project being run by a straight-out-of-college developer who felt that not only were comments unnecessary, they were actually a "code smell", a sign of professional incompetence on the part of whoever added them. It's an insane philosophy that could only appeal to people who have never had to take over an old codebase.
I kind of get the idea that code should be self-documenting, but at the same time, there's so many crazy business rules that comments are basically a necessity if nothing else other than to explain why in the hell the crazed mess that provides the required functionality for the business rules exists.
Yeah some comments are not useful
# returns the value as a string
return str(user.id)
Some comments are
# returns the user id as a string because ZenDesk's API throws errors if it gets a number.
# See ticket RA-1037
# See ZenDesk docs: https://etc/
return str(user.id)
Or, it appeals to people that have had had to take over an old codebase where the comments were all lies.
“Code never lies. Comments sometimes do.”
It's funny, the exact same logic applies to method and variable names. There's no compiler that ensures that a method's name accurately describes what the method does or ensures that a variable's name accurately describes what the variable represents. Yet nobody ever says "you shouldn't use descriptive method and variable names because they might be misleading". And this is hardly academic: I can't count the number of times I've run into methods that no longer do what the method name implies they do.
And yet method and variable names are exactly what people mean when they talk about "self-documenting" code.
I didn't even know we were hiring ...
Jesus i worked at exactly this kind of project once. The only other dev was also very hostile and protective of this position. He did not want me there in the slightest. Took about 6 months before we cancelled the contract since this dude was just actively harrassing me in Teams DMs on the daily and he just ignored all my concerns regarding maintainability since "he could understand the code" and i was probably just "not experienced enough".
Don't downplay what this does to your mental health. 5 years of workplaces like this and I'm now starting to see a therapist due to exhaustion disorder symptoms in my goddamn 20s. Take care our there!
I'll get shit on for suggesting it but this is a great use case for AI: comment the code and generate some basic docs. Even if it's wrong it'll give you a sense of where to start looking for flows.
I've been doing this for years at my current job. It has become a masterpiece of refactoring and comments. They weren't even asking the right questions. I'm very proud of myself.
So naturally, I'm about to get fired and have the whole thing redone by AI.
Then re-hired for 3x salary to make it work again, I hope. Or just watch the company/project fail spectacularly
ARGH this triggered a bit of PTSD for me....
"We're going to convert these COBOL applications to C#, and you need to test that the new application works exactly the same, including the same bugs as the old application."
"Ok, where's the specifications and test reports of the old COBOL applications?"
"They were lost to time, we don't know where they are."
"Ok, so how are the developers going to write the C# code?"
"They're going to read the COBOL scripts and recreate them into C#, we advise you do the same."
Cue me spending a month trying to decypher the COBOL gobbledigook into inputs and outputs, and write testcases based on that. And after that month was up, and I had delivered my testcases, they told me that my services were no longer needed.
#include "globals.h"
// please help
longest file I have ever maintained contained 50,000 lines of code.
fifty THOUSAND.
forgive me for not weeping for 2000 lines.
my advice, don't fucking touch it. pull out as much functionality out of it into other things over time.
there will come a day when you can throw it away. maybe not today, maybe not tomorrow... but some day.
Yeah, been there. The codebase I worked on also had a single method with 10k lines.
The database IDs were strings including the hostname of the machine that wrote to the DB. Since it was a centralized server, all IDs had the same hostname. The ID also included date and time accurate to the millisecond, and the table name itself.
Me: Mom, can we have UUIDs? Mom: We have UUIDs at home UUIDs at home: that shit
You should add the local weather forecast, a random fun fact and the canteen menu of the day to the key to make it more interesting to read.
Reject merge.
Documentation is part of design.
Do it or die in obscurity.
Something that I'm disproportionately proud of is that my contributions to open source software are a few minor documentation improvements. One of those times, the docs were wrong and it took me ages to figure out how to do the thing I was trying to do. After I solved it, I was annoyed at the documentation being wrong, and fixed it before submitting a pull request.
I've not yet made any code contributions to open source, but there have been a few people on Lemmy who helped me to realise I shouldn't diminish my contribution because good documentation is essential, but often neglected.
Those are rookie numbers. We got functions with 5000+ lines and 20 levels of indentation directly in the user-interaction event handlers :)
That time I started a new job and my first task was "fix bash"...and then I discovered a multi megabyte monstrosity called "bash.sh"
I literally told my boss that I was just going to rebuild the entire pipeline from the ground up when I took over the codebase. The legacy code is a massive pile of patchwork spaghetti that takes days just to track down where things are happening because someone, in their infinite wisdom, decided to just pass a dictionary around and add/remove shit from it so there is no actual way to find where or when anything is done.
I just inherited my first codebase a few months ago. It's like this everywhere and original developer was fired, so what should sometimes be a simple fix turns into a full day of finding what needs to change. Any recommendations on fixing/maintaining code like this or should I just make it the next person's problem?
if it's not in git / SVC, add it as is. Create a "refactor" branch, and liberally use commits
Treat it like a decompilation
Figure out what something does, and rename it (with a stupidly verbose name, if you have to). Use the IDE refactor tools to rename all instances of that identifier
Take a function, figure out what it does, and refactor it in a way that makes sense to you
Use the editor's diff mode to compare duplicate code, extract out anything different into a variable or callback, and combine the code into a function call. Vscode's "select for compare" and "compare with selected" are useful for this
Track what you're doing / keep notes in something like Obsidian. You can use [[Wikilinks]] syntax to link between notes, which lets you build a graph structure using your notes as nodes
be cognizant of "Side Effects"
For example, a function or property, or class might be invoked using Reflection, via a string literal (or even worse, a constructed string). And renaming it can cause a reflective invocation somewhere else random to fail
Or function or operator overloading/overiding doing something bizarre
Or two tightly coupled objects that mutate each other, and expect certain unstated invariants to be held (like, foo() can only be called once, or thingyA.len() must equal thingyB.len()
You can use these to more thoroughly compare behavior between the original and a refactor
Separate out those "concerns", into their own object/interface, and pass them into the class / function at invocation (Dependency Injection)
public Value? Func(String arg) {
if (arg.IsEmpty()) {
return null;
}
if (this.Bar == null) {
return null;
}
// ...
return new Value();
/// instead of
if (!arg.IsEmpty) {
if (this.Bar != null) {
// ...
return new Value();
}
}
return null;
}
I’m dealing with this currently. Thank you all for confirming that I’m not crazy
Then you fix 90% of a problem and get blamed when the rest of 10% doesn't work
"Documenting the code base will be your first task for the next month to help show us how well you understand the codebase."
"Code IS documentation"
I was part of project that scoffed at the idea documenting code. Comments were also few and far between. In retrospective, it really seemed like they wanted to give that elitist feel because everything reeked of wanting to keep things under wraps despite everything being done out in the freakin' open.
