junior dev: can you please give me an example of useful comments in my code?
Me: sure, good comments look like this ⤵️
junior dev: can you please give me an example of useful comments in my code?
Me: sure, good comments look like this ⤵️
@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.
@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 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)
@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.
@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's point here is simple:
there's certain kinds of code that if you touch it it will kill you
// 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
@nixCraft most comments:
// This is a thing
Another proof that clear, self explanatory code is always better than a thousand comments.
JAVASCRIPT TOWARD ENEMY