Same with BIOS descriptions.
FGTSAB switch [toggles the FGTSAB setting]
infuriating
It’s so bad it’s almost artistic
You mean autistic.
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.
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.
Snapmaker Luban is amazing with its help messages.
Every setting in this 3D slicer is completely explained how the setting works, what the different options are, with pictures and even what every option is the most optimal in whatever situation.
Too bad that it isn’t the best program unless you have a Snapmaker, and even then…
Love having to enable “support for sleep state 5” to turn off USB power when the PC is off
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.
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.
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.
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.
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
I meant to say commits and not merges, and yes he removed the comments before committing. It made no difference in long run because every new release broke all the accessibility stuff anyway. It’s amazing how little developers can be made to care about blind people - almost as little as managers. The only reason my company cared at all was they were facing million-dollar-a-month fines from the FCC.
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
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
Inline comments yes.
Function/Class/Module doc comments should absolutely explain “what”.
//@TODO document this function later15 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
/* * 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.
This being a double physically hurts
Makes sense, people looking for int would find a double
Happy cake day!
Fs.?g??yy V>
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.
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.
It definitely feels great when I get to remove the
//hack abc due to bug in library xyz version 1.4.5, issue tracker says it’s fixed in 1.5.0. - link
this is why i very rarely comment with descriptive comments. If you’re reading my code and don’t understand what it is, even with how shit it is, you have no business reading whatever fucking crackpot shit im writing.
