Exactly, that’s what I learned, too. “Be nice to future you!”
The rule isn’t generally “no comments”, it’s avoid useless comments. Like, don’t simply describe the code that you’ve written. That should be obvious to the reader.
Not useful:
// Declare an integer i and set it to 0
int i = 0;
// Add 2 to i
i += 2;
Exception of course is if you’re coding in something like a low level machine language where it may not be obvious what you’re doing.
Whether you want it or not!
In my experience people are just really bad at this. You have the rubber stampers who don’t really look at it. You have the nitpickers that want everything perfect and won’t accept that sometimes it’s necessary to just get the damn code integrated and fix stuff a little later, and others don’t even bother to ever review PRs without constant nagging.
I also think that people don’t make good enough use of static analysis tools which should make PRs more about looking at the intent/design of the change rather than nitpicking stupid stuff that could have been found by automated tooling.
/* fuck this shit */
Meanwhile that code inspires terror in me because it looks like you should just set i = 2, I can’t imagine any reason you wouldn’t do it that way, so what horrific eldritch problem is hiding in this code waiting to be triggered by something simple like setting a variable. And yeah, that should have a comment. 
I dream of this same thing. I don’t care if you can regurgitate CS 101 concepts on a whiteboard. Show me how you handle unfamiliar code written by (evidently) a chimpanzee with a VT 220 and an axe to grind.
If a candidate can look into the codebase and actually call out good things, that tells me a lot.
My first programming job the interviewer showed me the code base and asked if I could work with it.
I was “Sure. Did you know there was a bug here, and one here?”. His jaw dropped and I started on the spot.
… but without the addition, how can we know that the carry bit is clear 
no, see. the global += is overridden for integers and has the side effect of keeping a running total in a global variable. ( the global variable, of course, gets accessed by multiple threads, reset based on a timer, and is exported to other modules via a pointer of some completely different name. )
“Make sure the source tells me why you’ve made the choices you did here” is especially true for any “magic numbers” you may use. One of the more famous sweary comments I’m aware of is in the fast inverse square root code from Quake III Arena related to the magic number it (ab)uses.
Yah, tricks like that come from books like Graphics Gems and Hacker’s Delight, which don’t always fully prove out what they are doing. They are written so programmers (like Carmack) who are in a hurry and just want a fast solution to a problem can drop something in without necessarily totally grokking how it works. You see similar things in line/plane intersection code, perspective transformations, fixed point math, and other things where the traditional math would be slow, but clever hacks on bit patterns to get approximations are possible. I think we all had a good laugh the first time we saw Carmack’s comment there because we felt what he felt. “I can see with my eyes that this code works but holy hell why does it work”
To expand on what must seem like a throwaway comment: I missed having to use punchcards for my FORTRAN 77 course at uni by exactly one year. Not because of my prof who looked like Konrad Zuse’s dad and was the only one still using them and didn’t want to change anything about the way he taught just before he was due to retire anyway. No, the card reader for the CDC Cyber soandso finally broke and the Rechenzentrum flat out refused to have it repaired or replaced (not that you could have bought a new one then). The reader broke some time in 1985.
But I did end up going through stacks of punchcards and listings to evaluate existing programmes - would it be worth “porting” them by typing them into a terminal? Re-write them from scratch, maybe even using another language? So yeah, lots of comments scribbled on the cards.
Mostly programmes for either photogrammetry or stress analysis using laser stereophotography and strain gauges. FFTs, anyone?
This topic was automatically closed after 5 days. New replies are no longer allowed.
