Same with BIOS descriptions.
FGTSAB switch [toggles the FGTSAB setting]
infuriating
An autistic coder would have documented this feature to the point of pedantry.
Yup, my first thought as well. While those days are thankfully over, those braindead BIOS “help” messages remain etched into my mind forever.
Are the recent ones any better? I got a gigabyte b660m for 12th gen intel and it’s really bad at that. Had to look up a lot to figure out things.
Maybe it’s an ASUS thing but both my current and previous boards have been pretty good with the help texts.
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 told them I'd do this but only if they gave me time next sprint to fix it - 12-03-1997
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.
Well, this is shitty
I hope the reviewer did not also squash commits, and the next programmer would be able to at least dig what was there.
Doing changes after some rockstar dev implemented some really complex service, but left no clues as to what does what is so frustrating, and I can never be sure that I don’t break anything in a different place completely
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.
Out management used to tell us, that even if head of department had committed to doing something some way, there’s no way or need to hold them accountable. It’s just that situation has changed, and nobody should bat an eye.
To be fair, they also did not pressure us much for the missed deadlines or missing features, because it was indeed the result of the situation described in the first paragraph
/*
* Gets stupidFuckingInteger
*
* @returns stupidFuckingInteger
*/
public double getStupidFuckingInteger() {
return stupidFuckingInteger;
}
Reminds me of a job I had where c# summaries were mandatory and people used a documentation generator just like that.
/// Ages the Category. public int AgeCategory (…)
//@TODO document this function later
15 years later
Have reviewed 16 year old code for a very well known company in the last week with this exact comment peppered throughout, alongside delightfully helpful comments like:
// do not delete or change this it just works
// TODO temporary fix added 12/09/11 to fix incident must be removed ASAP
// CAUTION this returns false here instead of true like it normally does, not sure why
// if true then matched to valid account not is true
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
Describing the what also helps when you dabble in a new technology or little-used technology. It helps to explain to yourself what you’re doing and it helps in onboarding. “Hey, newbie, there’s a function in XYZ module that’s extensively documented. Look there for guidance.”
Inline comments yes.
Function/Class/Module doc comments should absolutely explain “what”.
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.
Unless you’re working with people who are too smart, then sometimes the code only explains the how. Why did the log processor have thousands of lines about Hilbert Curves? I never could figure it out even after talking with the person that wrote it.
