10 years ago? Try 10 days ago. 10 days ago me was an IDIOT
…but not to excess.
These are pretty sweary:
5 Likes
always write tests first, then port. this is the way
i always wonder, was i drinking again? my former self often makes the stupidest of mistakes. i don’t understand him at all. seriously.
3 Likes
In every complex problem there are points where it’s frustrating and you can’t figure out why it doesn’t work and most of us start swearing (my Mormon colleague would never swear in code or speach).
If my code comments get sweary or just odd its mostly a sign I didn’t give up and fought through to figure it out (someone recently pointed out that a model I published in 2018 has a comment “this is a madhouse, but its a madhouse of my own making. I can change it”).
Swearing in code comments might just indicate the coder didn’t give up when pushed to the point of screaming obscenities at the computer
4 Likes
Just out of idle curiosity, has your boss ordered you to show him screenshots of your code so he can evaluate it?
8 Likes
Beautiful example of the advice I was given early in my career: “Write your comments as though your code was going to be maintained by a violent psychopath who knows where you live.”
5 Likes
Back in my coding days: I had occasions where, a year or so after creating some new code, I went back to it to add new functionality. Invariably these two thoughts would arise while reviewing:
- wow, was I drunk when I wrote this?
- how the hell does this even work properly (and yet, it did…)
5 Likes
I, too, wrote Perl. 
aka, “either this is a brilliant regex, or the cat jumped on the keyboard”
6 Likes
I have had so many arguments with no-comment purists who are apparently convinced that their code is so special that it needs no comments for context, business cases, “we did this because something else has a bug”, etc.
“But the comments always get out of sync!” Then you are neglecting to make the necessary changes in your code when it needs to be fixed, aren’t you?
6 Likes
This was actually video processing code in C++. There were definitely a few sections where I’d clearly used a lot of trial and error to get the desired result, and returning to the code later I had a much better picture of how the process worked - and could usually optimise and simplify at that point.
2 Likes
I can’t even fathom this argument. Me: “the code is right there. If you can’t fix the comment when you fixed the code, stay out of src/”
5 Likes
So, when you write your comments on the punchcards, do you use a pencil or a biro?
3 Likes
I mean, OK, but daily I read comments that aren’t true about the code that follows them, usually because they were once true but changed.
I think it’s possible to be wrong about comments in both directions. I have coworkers who comment almost every line and it’ll be like
initialize x to 1
x = 1
And I know people who almost never comment. I am not a prolific commentor. Instead, we do PRs with each other, and we try to do a good job, Before I submit a PR of my own, I review my own code. I start writing comments on the PR that indicate what things are - usually it’s stuff like “the reason this is being removed here is I moved it to file X” or “this is no longer used” etc. But if I start writing stuff that explains why something is implemented the way it is, I usually delete that PR comment and put it in the code.
I usually also take this personal-PR-review-time to look at functions I added and see if they’re completely described by their name and arguments, like “add_post_to_user(user_id, post_id)” or if there is something subtle or unexpected or not completely described from the name. I usually end up adding at least a docstring comment that says what the function is (and is NOT) for.
I don’t think there are good hard and fast rules. It’s an art and a moving target and I accept that I am often wrong about how much I comment. If anyone asks for more detail I will always go back and add it. It can be very difficult because I am experienced and good at reading code - I am way more likely to look at the code for a library than it’s documentation.
2 Likes
It’s just the laziest possible argument for “comments are bad”.
Comments are bad? Cool. Make sure the source tells me why you’ve made the choices you did here. And I will bounce it in code review until it does.
2 Likes
I use columns 40-71, and insert comment cards. That’s what they’re for.
2 Likes
Yeah, right.
1 Like
It is an art, so any blanket statement like “all comments are bad” or “every comment is valuable” is definitely ignoring the art.
“Why this change?” is PR territory. “Why this algorithm?” is an embedded comment. “What this code does” is usually the code itself. Those are my rules of thumb, anyway, flexible based on circumstances.
5 Likes
And actually I feel like PRs are an art too.
I’ve been responsible for hiring at most of my jobs in the last 7 or 8 years, and I feel like I’ve never landed on a great method for evaluating people, aside from actually working with them for 3 months. But I sometimes dream about an interview exercise where you’re presented with a PR and you need to review it. The code will have some bugs, some code smells, some inelegances, whatever. Nothing tricky, I am not trying to find out if people really really know their edge cases, just like, how do you tackle a PR.
I could be wrong but I think solid PR skills are a top tier talent. As above I told you that 10-days-ago me is an idiot, so I need someone who hasn’t been staring at the code for a week to look for things I didn’t think about, tests I didn’t write, other bits of code and libraries I could have leveraged instead of rewriting, just in general like, a sanity check. A rubber-stamper does no one any good, and someone who gets tied up in the “I want this to be in my style” isn’t helpful either (this is a problem of my own, I’m working on it)
3 Likes
Don’t overshoot the Ballmer peak. It tails off pretty sharply after 0.138.
5 Likes
