this post was submitted on 06 Jul 2024
1090 points (99.5% liked)

Programmer Humor

19623 readers
507 users here now

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.

Rules

founded 1 year ago
MODERATORS
top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 175 points 4 months ago (4 children)

Same with BIOS descriptions.

FGTSAB switch [toggles the FGTSAB setting]

infuriating

[–] [email protected] 30 points 4 months ago
[–] [email protected] 19 points 4 months ago (4 children)

It's so bad it's almost artistic

load more comments (4 replies)
[–] [email protected] 8 points 4 months ago (3 children)

Yup, my first thought as well. While those days are thankfully over, those braindead BIOS "help" messages remain etched into my mind forever.

load more comments (3 replies)
load more comments (1 replies)
[–] [email protected] 107 points 4 months ago (4 children)

Best comment ever was "It used to work like this but person at client demanded it work like that on this date" when the client complained it shouldn't work like that.

[–] [email protected] 112 points 4 months ago (4 children)

That's basically what comments are most useful for. When you're doing something that's not obvious, and want to make sure the "why" doesn't get lost to time.

[–] [email protected] 77 points 4 months ago (2 children)

// I'm not really that dumb, there is a reason.

[–] [email protected] 32 points 4 months ago

// narrator: the reason was management

[–] [email protected] 17 points 4 months ago* (last edited 4 months ago) (1 children)
// I told them I'd do this but only if they gave me time next sprint to fix it  - 12-03-1997
[–] [email protected] 7 points 4 months ago

[flashbacks to the backlog being wiped out because “the client already signed off on the release”]

load more comments (3 replies)
[–] [email protected] 62 points 4 months ago

The best comments are "why" comments, the runner up is "how" comments if high-level enough, and maybe just don't write "what" comments at all because everyone reading your code knows how to read code.

[–] [email protected] 14 points 4 months ago

this seems like a great idea as it provides proof in writing just in case the stakeholder complains later on about the thing you implemented at their request

[–] [email protected] 5 points 4 months ago

That’s actually the perfect comment, because if anyone ever comes back to fuck with you about it, it’s explained right there. Then you turn it right back around on management and watch them run around like chickens with their heads cut off.

[–] [email protected] 93 points 4 months ago (3 children)
/*
 * Gets stupidFuckingInteger
 *
 * @returns stupidFuckingInteger
*/
public double getStupidFuckingInteger() {
    return stupidFuckingInteger;
}

[–] [email protected] 32 points 4 months ago* (last edited 4 months ago) (1 children)

The lack of a return type declaration makes this sooo good.

[–] [email protected] 18 points 4 months ago* (last edited 4 months ago) (1 children)

It has the return type declared to be double.

[–] [email protected] 5 points 4 months ago

I cannot read. Even better.

[–] [email protected] 12 points 4 months ago (1 children)

Makes sense, people looking for int would find a double

load more comments (1 replies)
load more comments (1 replies)
[–] [email protected] 66 points 4 months ago* (last edited 4 months ago) (1 children)

//@TODO document this function later

15 years later

load more comments (1 replies)
[–] [email protected] 58 points 4 months ago (6 children)

Comments should explain "why", the code already explains "what".

[–] [email protected] 47 points 4 months ago* (last edited 4 months ago) (2 children)

The allowable exception is when the what is a what the fuck, as in you had to use a hack so horrible that it requires an apology comment

[–] [email protected] 9 points 4 months ago

Absolutely, although I see that as part of why

Why is there a horrible hack here? Because stupid reason...

load more comments (1 replies)
[–] [email protected] 21 points 4 months ago (1 children)

Inline comments yes.

Function/Class/Module doc comments should absolutely explain "what".

[–] [email protected] 6 points 4 months ago (1 children)

You are absolutely right. It was inline comments I had in mind.

[–] [email protected] 5 points 4 months ago

I don't code, at best I script. I'm a sysadmin, not a dev, so I play around in PowerShell mostly.

I just started to naturally do all of this. Not because I was taught to, but because I've written too many scripts that I later looked at, and thought, WTF is going on here.... Who tf wrote this? (Of course it was me)...

So instead of confusing my future self, I started putting in comments. One at the beginning to describe what the file name can't, and inline comments to step me through what's happening, and more importantly why I did what I did.

The sheer number of comments can sometimes double the number of lines in my script, but later when I'm staring into the abyss of what I wrote, I appreciate me.

load more comments (4 replies)
[–] [email protected] 41 points 4 months ago (8 children)

I write such comments because I have to.

Company policy.

Also we have to specify every line of code and what it should do.......

[–] [email protected] 45 points 4 months ago

Lol leave. That is so many levels of braindead.

[–] [email protected] 21 points 4 months ago (1 children)

I would smash everything into a handful of overly-complicated lines.

[–] [email protected] 7 points 4 months ago (1 children)

I loved doing this is school, just trying to mess up my teachers.

load more comments (1 replies)
load more comments (6 replies)
[–] [email protected] 29 points 4 months ago* (last edited 4 months ago) (1 children)

/********** Setting up the fkuArray **********/

fkuArray = array(...

[–] [email protected] 15 points 4 months ago

Well, fku that array indeed.

[–] [email protected] 26 points 4 months ago (14 children)

I had a old job that told me that code is "self documenting" if you write it "good enough". And that comments were unnecessary.

It always annoyed the heck out of me. Comments are imo more helpful than hurtful typically.

Is it just me? Or am I weird? Lol.

[–] [email protected] 37 points 4 months ago* (last edited 4 months ago)

Document intentions and decisions, not code.

[–] [email protected] 29 points 4 months ago (1 children)

Code should always by itself document the "how" of the code, otherwise the code most likely isn't good enough. Something the code can never do is explain the "why" of the code, something that a lot of programmers skip. If you ever find yourself explaining the "how" in the comments, maybe run through the code once more and see if something can be simplified or variables can get more descriptive names.

For me, that's what was originally meant with self-documenting code. A shame lazy programmers hijacked the term in order to avoid writing any documentation.

[–] [email protected] 8 points 4 months ago (1 children)

lazy programmers

I don't think they're lazy, I think they're not good writers. Not being able to write well is very common among programmers (not having to communicate with written language is one reason a lot of people go into coding) and in my experience the Venn diagrams for "not a good writer" and "thinks comments are unnecessary" overlap perfectly.

load more comments (1 replies)
[–] [email protected] 6 points 4 months ago

Its definitely a balance. Good code shouldn't need much commenting, but sometimes you have to do something for a reason that isn't immediately obvious and that's when comments are most useful. If you're just explaining what a snippet does instead of why you're doing it that way, there's probably more work to be done.

load more comments (11 replies)
[–] [email protected] 9 points 4 months ago* (last edited 4 months ago) (2 children)

The code is self explanatory

/s needed apparently

[–] [email protected] 13 points 4 months ago

The words of the machine are sacred, Only the impure need explanation

The Flesh is Weak

[–] [email protected] 5 points 4 months ago

It explains what it does, it does not confirm that it is what was intended.

[–] [email protected] 9 points 4 months ago (1 children)
load more comments (1 replies)
[–] [email protected] 6 points 4 months ago (4 children)

How bad programmers comment their code. Good programmers don't comment at all and let the code speak for itself, leaving commenting to some obscure and arcane implementation the coder left in after a week long binge on caffeine and gummy bears.

[–] [email protected] 14 points 4 months ago (2 children)

"What does this section of code do?"

Run it and find out, coward.

load more comments (2 replies)
[–] [email protected] 9 points 4 months ago* (last edited 4 months ago) (2 children)

Code should absolutely speak for itself. But the occasional comment is still good to explain the 'why' of the code when the why isn't very obvious, often due to a niche requirement. Also any time you have to break out a hack, that needs comments up the ass, what was the bug, what URL did you find the fix at, why does this hack work, etc etc. It's very satisfying to go back and remove those hacks after they are no longer needed, often because the underlying technology fixed the bug that had to be hacked around.

load more comments (2 replies)
[–] [email protected] 6 points 4 months ago* (last edited 4 months ago) (1 children)

This is the truth. In my experience, the people who often writes comments are also writing the most incomprehensible code.

Comments are frequently getting outdated as well, so they’re not in great help understanding the code either.

load more comments (1 replies)
[–] [email protected] 5 points 4 months ago (1 children)
load more comments (1 replies)
load more comments
view more: next ›