Same with BIOS descriptions.
FGTSAB switch [toggles the FGTSAB setting]
infuriating
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.
Same with BIOS descriptions.
FGTSAB switch [toggles the FGTSAB setting]
infuriating
I love it
Yup, my first thought as well. While those days are thankfully over, those braindead BIOS "help" messages remain etched into my mind forever.
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.
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.
// I'm not really that dumb, there is a reason.
// narrator: the reason was management
// I told them I'd do this but only if they gave me time next sprint to fix it - 12-03-1997
[flashbacks to the backlog being wiped out because “the client already signed off on the release”]
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.
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
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.
/*
* Gets stupidFuckingInteger
*
* @returns stupidFuckingInteger
*/
public double getStupidFuckingInteger() {
return stupidFuckingInteger;
}
The lack of a return type declaration makes this sooo good.
It has the return type declared to be double
.
I cannot read. Even better.
This being a double physically hurts
Comments should explain "why", the code already explains "what".
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
Absolutely, although I see that as part of why
Why is there a horrible hack here? Because stupid reason...
Inline comments yes.
Function/Class/Module doc comments should absolutely explain "what".
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.
Document intentions and decisions, not code.
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.
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.
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
Code is the what. Comments are the why.
Few things worse than an out of date comment.
Have you ever worked in a place where every function/field needed a comment? Most of those comments end up being "This is the , or this does ". Beyond, being useless, those comments are counter productive. The amount of screen space they take up (even if greyed out by the IDE) significantly hurts legability.
Code is not self documenting when decision trees are created based on some methodology that's not extremely obvious
I write such comments because I have to.
Company policy.
Also we have to specify every line of code and what it should do.......
Lol leave. That is so many levels of braindead.
I would smash everything into a handful of overly-complicated lines.
/********** Setting up the fkuArray **********/
fkuArray = array(...
Well, fku that array indeed.
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.
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.
Yes. This 1000x. I hate it at work when I come across code that was written 3 years ago that has literally no traces of why it's there and a quick summary of what it does. Especially because that code is always the most abbreviated spaghetti you've ever seen. People should stop thinking (their) code documents itself because 99.999% of programmers cannot do it right.
I really like the Google way of coding: assume the person reading the code is the most 1337 programmer ever, BUT that this person knows absolutely nothing about the project
This is something a lot of people don't seem to understand. Even if code is self-explanatory, I want to know why it was designed that way.
I've fixed bugs where the fix was only a one line change, but it was extremely difficult to figure out, so I left a 10ish line comment above it explaining why it has to be done that way.
Hard disagree. It's a lot easier and faster to understand a function that is prefaced with a small line of text explaining what it does rather than trying to figure it out yourself.
It's not about whether you can understand the code or not, it's about efficiency and clarity.
I got a media failed to load error at first and thought that was the joke
The code is self explanatory
/s needed apparently
The words of the machine are sacred, Only the impure need explanation