I can’t magine why you’d feel the need to don that flame-retardant bunny suit for making a pragmatic comment like that.   I rely much more on comments than on code for understanding even what I myself have done.   That is nothing more or less than a pragmatic survival skill.

I also categorically reject the viewpoint of people who say, perhaps in the name of “don’t repeat yourself,” that you have to write code as succinctly as possible.   For example, I recently got lambasted by someone who didn’t like me writing this:

if (something_1_fails()) {
 ... do something ...
}
if (something_2_fails()) {
  ... do the same thing ...
}
[download]

This person’s murderously-held opinion being that the only proper way to write it was:

if (something_1_fails() || something_2_fails()) {
  ... do something ...
}
[download]

such that it was absolutely “my way or the highway.”   My contrasting point-of-view simply being that:

• It makes absolutely no pragmatic difference to the Perl compiler and/or to a modern-day machine, but...
• The day will come when you want to change that code, perhaps in some slight way, and now you find that you have coupled these two pieces of code and/or behavior tightly together.   The two responses might be identical now, but the reasons for those responses are not the same and in fact they never will be.
• (Key Idea...) Whether the response today is identical or not is not the point; whether the code is “more efficient” today is also not the point:   the concerns are different, therefore in months and years to come there is no reason to suppose that the responses will be different.   In order to correctly maintain the “only proper way” code anytime in the future, you are going to have to figure out both routines and (correctly...) judge how to prize them apart.   What ought to be a “no-thought modification,” say to tweak an error-message, suddenly requires thought.   All to gain you ... what, exactly?   (A: nothing.)

Your thoughts always become the thoughts of a stranger, and you always re-discover those thoughts every time you go back to any piece of code .. in any language.   How well you documented those thoughts, and how cleanly you made those thoughts, truly makes all the difference in the world over the sometimes decades-long life span of a commercial application.