this post was submitted on 06 Jul 2024
1418 points (99.4% liked)

Programmer Humor

24670 readers
288 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 2 years ago
MODERATORS
top 50 comments
sorted by: hot top controversial new old
[–] Honytawk@lemmy.zip 221 points 1 year ago (4 children)

Same with BIOS descriptions.

FGTSAB switch [toggles the FGTSAB setting]

infuriating

[–] Andromxda@lemmy.dbzer0.com 40 points 1 year ago
[–] Artyom@lemm.ee 34 points 1 year ago (4 children)

It's so bad it's almost artistic

load more comments (4 replies)
[–] BenLeMan@lemmy.world 11 points 1 year 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)
[–] SlopppyEngineer@lemmy.world 125 points 1 year ago (5 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.

[–] conciselyverbose@sh.itjust.works 127 points 1 year ago (2 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.

[–] kubica@fedia.io 89 points 1 year ago (2 children)

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

[–] DarkDarkHouse@lemmy.sdf.org 36 points 1 year ago

// narrator: the reason was management

[–] NotMyOldRedditName@lemmy.world 31 points 1 year ago* (last edited 1 year 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
[–] MostlyBlindGamer@rblind.com 13 points 1 year ago

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

[–] ChickenLadyLovesLife@lemmy.world 12 points 1 year ago (2 children)

I spent a year making my company's iOS apps accessible (meaning usable for the blind and people with vision disabilities). I had to do a lot of weird shit either because of bugs in Apple's VoiceOver technology or because of the strange way in which our code base was broken up into modules (some of which I did not have access to) and I would always put in comments explaining why I was doing what I was doing. The guy doing code review and merges would always just remove my comments (without any other changes) because he felt that not only were comments unnecessary but also they were a "code smell" indicating professional incompetence. I feel sorry for whoever had to deal with that stuff at a later point.

load more comments (2 replies)
[–] 0x0@lemmy.dbzer0.com 67 points 1 year 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.

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

[–] jaybone@lemmy.world 12 points 1 year ago (1 children)

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.

load more comments (1 replies)
load more comments (1 replies)
[–] yetAnotherUser@discuss.tchncs.de 109 points 1 year ago (4 children)
/*
 * Gets stupidFuckingInteger
 *
 * @returns stupidFuckingInteger
*/
public double getStupidFuckingInteger() {
    return stupidFuckingInteger;
}

[–] mrpants@midwest.social 37 points 1 year ago* (last edited 1 year ago) (1 children)

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

[–] expr@programming.dev 26 points 1 year ago* (last edited 1 year ago) (1 children)

It has the return type declared to be double.

[–] mrpants@midwest.social 16 points 1 year ago

I cannot read. Even better.

[–] Amir@lemmy.ml 16 points 1 year ago

This being a double physically hurts

[–] ILikeBoobies@lemmy.ca 15 points 1 year ago (1 children)

Makes sense, people looking for int would find a double

load more comments (1 replies)
load more comments (1 replies)
[–] cupcakezealot@lemmy.blahaj.zone 72 points 1 year ago* (last edited 1 year ago) (1 children)

//@TODO document this function later

15 years later

load more comments (1 replies)
[–] mundane@feddit.nu 69 points 1 year ago (6 children)

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

[–] smeg@feddit.uk 58 points 1 year ago* (last edited 1 year ago) (3 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

[–] mundane@feddit.nu 13 points 1 year ago

Absolutely, although I see that as part of why

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

load more comments (2 replies)
[–] calcopiritus@lemmy.world 25 points 1 year ago (3 children)

Inline comments yes.

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

load more comments (3 replies)
load more comments (4 replies)
[–] AlexCory21@lemmy.world 55 points 1 year ago (21 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.

[–] alonely0@programming.dev 50 points 1 year ago* (last edited 1 year ago)

Document intentions and decisions, not code.

[–] VonReposti@feddit.dk 38 points 1 year 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.

[–] ChickenLadyLovesLife@lemmy.world 11 points 1 year 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)
[–] Vigge93@lemmy.world 24 points 1 year ago* (last edited 1 year ago) (2 children)

Comment should describe "why?", not "how?", or "what?", and only when the "why?" is not intuitive.

The problem with comments arise when you update the code but not the comments. This leads to incorrect comments, which might do more harm than no comments at all.

E.g. Good comment: "This workaround is due to a bug in xyz"

Bad comment: "Set variable x to value y"

Note: this only concerns code comments, docstrings are still a good idea, as long as they are maintained

load more comments (2 replies)
[–] Daxtron2@startrek.website 10 points 1 year 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.

[–] AdNecrias@lemmy.pt 10 points 1 year ago

Good code is self documenting as in you don't need to describe what it is doing and it is clear to read. Whoever says that and isn't just repeating what they heard understands that whenever you are doing something not explicit in the code it should be on a comment.

Workarounds and explaining you need to use this structure instead of another for some reason are clear examples, but business hints are another useful comment. Or sectioning the process (though I prefer descriptive private functions or pragma regions for that).

It also addresses the hint that the code should be readable because you're not going to have comments to explain spaghetti. Just a hint, doesn't prevent it. Others also said it, comments are easier to get outdated as you don't have the compiler to assist. And outdated comments lead to confusion.

[–] Amir@lemmy.ml 10 points 1 year ago

Code is not self documenting when decision trees are created based on some methodology that's not extremely obvious

[–] Blackmist@feddit.uk 9 points 1 year ago

Code is the what. Comments are the why.

Few things worse than an out of date comment.

load more comments (14 replies)
[–] Johanno@feddit.org 48 points 1 year ago (10 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.......

[–] jas0n@lemmy.world 51 points 1 year ago

Lol leave. That is so many levels of braindead.

[–] explodicle@sh.itjust.works 26 points 1 year ago (1 children)

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

[–] MystikIncarnate@lemmy.ca 12 points 1 year ago (2 children)

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

load more comments (2 replies)
[–] jaybone@lemmy.world 8 points 1 year ago (1 children)

// this line increments the value of i by 1

i++;

load more comments (1 replies)
load more comments (7 replies)
[–] shundi82@sh.itjust.works 30 points 1 year ago* (last edited 1 year ago) (1 children)

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

fkuArray = array(...

[–] Hupf@feddit.de 17 points 1 year ago

Well, fku that array indeed.

[–] snaggen@programming.dev 15 points 1 year ago (1 children)
[–] Fargeol@lemmy.ml 8 points 1 year ago

answer: the answer

[–] nikaaa@lemmy.world 14 points 1 year ago (16 children)

Good code is self-explanatory. You should only comment your code if it does something unexpectedly complicated.

That being said, it's always a good idea to write a manual, about how to use the code. Don't document how it works, because those who can code will understand it anyways, and those who can't, have no need to understand it.

[–] BorgDrone@lemmy.one 10 points 1 year ago (3 children)

Good code is self-explanatory. You should only comment your code if it does something unexpectedly complicated.

The code shows what is being done. The comments should explain the why.

load more comments (3 replies)
load more comments (15 replies)
[–] Wild_Mastic@lemmy.world 11 points 1 year ago* (last edited 1 year ago) (2 children)

The code is self explanatory

/s needed apparently

[–] menas@lemmy.wtf 15 points 1 year ago

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

The Flesh is Weak

load more comments (1 replies)
load more comments
view more: next ›