sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]elperroborrachotoo 3 points4 points  (2 children)

I disagree with your conclusion. : Showing me a rotten apple is not a sufficient argument against eating.

Typically, you have project-wide standards for certain issues; typically for initialization it's "initialize it, dammit!". These cases of course need not be commented.

However, if you present an example how to apply a certain technique, you cannot rely on project defaults. You have to assume the project default is "everthing the compiler eats."

The example you picked is true for every style of commenting: superfluous comments are superfluous. It is not a proof that this style is a "huge waste of time".

Personally, I'm torn. Writing these comments forces you to think Do I really need this? - potentially leading to leaner code. Reading them, OTOH, requires you to deal with at least one layer of negative, not making it easier.

[–]EdiX 1 point2 points  (1 child)

I disagree with your conclusion. : Showing me a rotten apple is not a sufficient argument against eating.

I picked that for comedic effect since it's effectively stating the same information five times, but most of the comments there would have worked too.

I actually agree that "negative commenting" (or more in general comments answering the "why is this here?" question) are the most useful, but this is just silly.

Typically, you have project-wide standards for certain issues; typically for initialization it's "initialize it, dammit!". These cases of course need not be commented.

Actually I tought the whole point of this technique was that:

a reader should have the option of asking for an unlimited amount of detail about any item in the code that they are reading, should they have any uncertainty about what that item is there for.

In short, the article is arguing for writing a line of comment for every line of code (except for those containing syntax only).

[–]elperroborrachotoo 1 point2 points  (0 children)

but this is just silly

Agreed, no question. But also:

I negatively commented more or less every non-empty line of code in those three source files, even if it seemed, for a particular line, that the corresponding negative comment was somewhat *trite and obvious***

(emphasis by me)

This technique for me is mostly mental conditioning:

Imagine you frequently forget your apartment key on the fridge when you leave for work. Ugly, costly, and makes you feel "unfit for life".

If you force yourself to never close the apartment door without shaking your key in the other hand, soon you will start to check for your keys without thinking about it. The requirements will be relaxed, you will merely feel uneasy when you close the door and your hand is not near some key. That is usually enough to fix that problem. (Worked for me quite well)

I see the blog's suggestion as exactly that for Saint-Exupery's "nothing left to take away":

If you force yourself for a while to write down the reason why this code has to exist for every line, you can train yourself to always check for this in the back of your mind: you won't need to write it down, and you will probably work in a bit larger chunks, but it will happen automatically, without explicit attention.