junior dev: can you please give me an example of useful comments in my code?

Me: sure, good comments look like this ⤵️

@nixCraft No clue what a good comment looks like, most of mine are along the lines of "this is because device X with software version Y disregards spec and responds with frame Z instead of A"
@nixCraft That feels like a bug, not a feature
@Quantensalat @nixCraft It's an AH-1, it's bugs all the way down

@nixCraft If anyone finds this scenario odd, it's because this gun uses percussion primed cartridges, and the cam moves the firing pins as it rotates through the track.

Some other guns use electrically primed cartridges, which require DC voltage be applied. Stray volts are a thing though, so still not totally safe if powered off.

@CDubbs @nixCraft And nobody even considered driving it with gearing that's not backdrivable...

@dalias @CDubbs @nixCraft

Why would you? It just makes it needlessly complicated. The envelop for which it was designed for considers the only handlers to be trained not be incompetent.

@Madagascar_Sky @CDubbs @nixCraft My thought was randos, saboteurs, etc. in a combat zone.
@dalias @Madagascar_Sky @nixCraft This is actually a good example of defense in depth. It's highly unlikely it would always fire when loaded with rounds just before the firing position. There's likely an arming/safety pin too. It's just better to assume it will.
@dalias @Madagascar_Sky @CDubbs Well boy, won't the randos be surprised when they walk up to the military equipment and start playing with it...
@nixCraft AI: “I have understood the dangers, I suggest using your feet to rotate the gun”
@nixCraft Perfect metaphor. What I want to know was if the comment was added after the code's behavior was noted to have consequences unanticipated by the user.

@walshman23 @nixCraft As the saying goes, Tech Orders are written in blood.

Though more often, Tech Orders are written in "This investigation concludes that SrA Snuffy is not responsible for the Class B mishap because they followed all procedures required by Tech Order XYZ and was not otherwise trained to prevent the circumstances that led to the mishap."

@nixCraft
Typically American point of view 😝
@nixCraft one group of people will read this and think “I better not turn it or the gun will fire”, another group will read it and think “it can’t be that dangerous or they wouldn’t have told me to fire it by rotating it”. I’ve heard of the first group, never met them unfortunately.
@nixCraft every sign has a story: gatling gun edition

@nixCraft good comments explain if it does that on purpose, so you know if your "fix" to make it safer will actually break something else

(or to be boring and get away from the image, good comments answer "what were they even trying to *do* here?!", because The Code only tells you what they *actually* did)

@LionsPhil @nixCraft I'm pretty sure the unit tests explain if it does it on purpose or not

@EndlessMason @LionsPhil @nixCraft No, the unit tests explain if it's *always* done it, or if it's only just started.

Unit tests can be just as buggy as code, so you still need comments (or good naming) to explain the intent of *those*.

Your contention here is that there are tests that pass for a behaviour that's either not deliberate or is not correct.

If your test suite is like that you have bigger problems than somebody turning the gun and getting shot... you don't even know if the gun can do a get shot...

You're talking about a test suite that passes when they do get shot, or tests that pass when the gun jams.

@imsop @LionsPhil @nixCraft

@EndlessMason @LionsPhil @nixCraft
Yes. I'm talking about the real world, not a TDD textbook.

If you make a change and a test fails, is it a) because the test perfectly covers a requirement you hadn't accounted for; b) because the test implicitly covers the behaviour that you were intending to change; or c) because the test was just badly written, and relied on implementation details that don't actually matter?

Of course, comments and names can *also* be wrong, but they give you an extra clue as to what some previous developer *thought* both the code and the test were doing.

@nixCraft

nixcraft's point here is simple:

there's certain kinds of code that if you touch it it will kill you

@benroyce @nixCraft

// Dear maintainer:
//
// Once you are done trying to 'optimize' this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 42

Source:
https://stackoverflow.com/a/482129

#dev

What is the best comment in source code you have ever encountered?

What is the best comment in source code you have ever encountered?

Stack Overflow

@dusk @nixCraft

i like this:

// sometimes I believe compiler ignores all my comments

🤔

@nixCraft so do you think the warning was before or after a bad mistake

@nixCraft most comments:

// This is a thing

@nixCraft I wonder what came first the warning or the accidental firing.
@carbontwelve @nixCraft Given that we are talking about humans: both.
@nixCraft I feel like there is also an API design lesson waiting in this image
@nixCraft My favorite: // Thanks. I hate it.
@nixCraft Good comment, yet the placement is debatable
@shaedrich I mean, it's placed in the spot you're going to do the most harm to yourself if you don't heed the warning.

@nixCraft

Another proof that clear, self explanatory code is always better than a thousand comments.

@nixCraft it's a gatling-style rotary machine gun and the warning is printed on the "wrong" side of it, for the benefit of anyone trying to clean this thing or mess with it
@nixCraft Kind of makes me want to spin it ​
@nixCraft the kind of comments insurance forced you to put too late
@nixCraft Governmental Hacker groups creating a new Stuxnets be like
@nixCraft It's a warning and not an error - safe to ignore
@nixCraft
Henceforth I shall put that exact comment in all my.code.
@nixCraft When I write temporary code such as migration code, I add a FIXME/TEMP comment, with the date it should be removed, and I include the YEAR in the date.