Dankpods screen cap?
this post was submitted on 06 Jul 2024
1537 points (99.4% liked)
Programmer Humor
20090 readers
26 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
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
I write such comments because I have to.
Company policy.
Also we have to specify every line of code and what it should do.......
I feel like I am going to have to do the same thing in the end, to get my hand-over accepted.
Should I just copy the line of code and make a comment next to it with:
// It does <paste line of code>
Do you license every comment of yours? If yes, why? Tbh i'm just curious
Not every. The quick, very-low effort ones, I just leave.
Why:
I saw another post with "Anti Commercial AI License", then wen on to read the license and went, "Neat!".
- It makes it easier for anyone to decide what to do if they want to use my comment/post (in cases where it actually has something useful)
- It makes life just a bit harder for people data-mining for AI
- That way, some data entry worker will probably ask for a raise and probably even get it and maybe some entrepreneur going "AI everywhere!" will think twice.
- Or there will be a chatbot spouting "Anti Commercial AI License" or "CC By-NC-SA" in their answer text, which would be hilarious.
load more comments
(2 replies)
I would smash everything into a handful of overly-complicated lines.
Lol leave. That is so many levels of braindead.
load more comments
(4 replies)
/*
* Gets stupidFuckingInteger
*
* @returns stupidFuckingInteger
*/
public double getStupidFuckingInteger() {
return stupidFuckingInteger;
}
load more comments
(3 replies)
Same with BIOS descriptions.
FGTSAB switch [toggles the FGTSAB setting]
infuriating
I love it
load more comments
(10 replies)
Comments should explain "why", the code already explains "what".
Inline comments yes.
Function/Class/Module doc comments should absolutely explain "what".
You are absolutely right. It was inline comments I had in mind.
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
(1 replies)
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.
If you know how the code does something, you also know what it does.
"Smart"
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...
load more comments
(2 replies)
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.
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 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.
// I told them I'd do this but only if they gave me time next sprint to fix it - 12-03-1997
load more comments
(1 replies)
// narrator: the reason was management
load more comments
(3 replies)
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.
load more comments
(3 replies)
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
Yeah, hence me mentioning the arcane code nobody knows what it does.
"What does this section of code do?"
Run it and find out, coward.
Nah. It should be obvious by just looking at it in code. If it isn't, you haven't extracted single purpose methods out of it yet.
load more comments
(1 replies)
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.
I was rewriting some old code of mine and ended up stripping out the comments. I kept reading them instead of the code, which I had been changing, and they were irrelevant. (I added new comments back in, though a big reason to rewrite was to make the code more self-explanatory.)
The code is self explanatory
/s needed apparently
It explains what it does, it does not confirm that it is what was intended.
The words of the machine are sacred, Only the impure need explanation
/********** Setting up the fkuArray **********/
fkuArray = array(...
Well, fku that array indeed.