I don't understand this vitriol against all forms of code commenting. (I personally hate the useless, mostly empty function headers forced by some coding standard)
If the comments describe the code this means I have to ignore all comments including those which may be relevant to my debugging. This causes a few specific problems in a collaborative environment.
The first is that the comments get stale/out-of-date/etc, more quickly and are therefore consigned to the archaeology of the program rather than of current relevance. At least with spurious logging, I can take it as a sign that someone had trouble with the code here. With comments I cant even tell if it was done in pseudocode and then translated below. It is useless.
The second is that you can't just add relevant comments into the mess without deleting all the other comments first. Otherwise they can't be sorted out easily or efficiently. In other words, it is worse than useless because it keeps proper, useful comments from being seen or read.
Third, if there are relevant comments there, such as
# This is the maximum value the standard allows for.
Then I won't see these and I am more likely to miss them and hence screw something up by accident.
A better approach is to recognize two things:
1) The code itself needs to be so clear, that you never need any comments for debugging (interface documentation is something very different), and
2) The code plus the documentation together has to be easily readable to the programmer. It also needs to be clear, concise, and avoid duplicating messages any more than needed. Duplication with the documentation of course is required by definition.
I hear a lot of people say they have code they would like to release open source but don't want anyone to see how horrible the code is. The answer is to learn to write code with a dual audience --- human and computer --- in mind. The code comments then function like footnotes would in a text, or as a way for two or three programmers to discuss/debate differences in approach. However, they are not debugging aids.
# print out the value of x prior to increment print("x value prior to increment: %d" % x)
# increment the value of x x += 1
# print out the value of x after increment by one print("x value after increment by one: %d" % x)
// Increment the total
log.Debug("total before increment=" + total);
total++;
log.Debug("total after increment=" + total);
I sort of wish someone would allow comments and logging to be combined as language features.
It allows the specially-formatted comments to produce debugging output.
From the synopsis:
use Smart::Comments;
my $var = suspect_value();
### $var
### got: $var
### Now computing value...
# and when looping:
for my $big_num (@big_nums) { ### Factoring... done
factor($big_num);
}
while ($error > $tolerance) { ### Refining---> done
refine_approximation()
}
for (my $i=0; $i<$MAX_INT; $i++) { ### Working===[%] done
do_something_expensive_with($i);
}
Magic comments are evil, the pox of the earth, etc. I have nothing good to say about comments as code. This totally messes up the separation between code and comment.
There is sometimes more to code than readability, unfortunately. I have worked with functions thousands of lines long that can't be broken up without losing a few percentage points of speed - but these functions are called millions of times.
A single function for every 3-4 line operation would result in incredibly disjointed code, and would require more explicit documentation of invariants because that function can now be called elsewhere (at least inside of the given translation unit).
> A useful comments says why code is this way, it doesn't summarize or repeat code.
That's nonsensical. Why wouldn't you want to abstract the complex?
If you need a comment to say what the next four lines do, you need a function for that, not a comment.
A short, atomic unit of 4-6 lines of code does not deserve to be a function simply because it's an atomic unit, but it does warrant a simple comment that someone skimming the code can use as an index to determine where they want to look.
It's all about making the code approachable in bite size pieces for future maintainers, your collaborators, and your future self. Breaking it into pieces and describing the code means that maintainers are not required to trace out all the code and swap in a huge amount of knowledge just to determine what a given function does, and why, and what is safe to change within it.
And I couldn't disagree more with that statement, and virtually everything you've said. Maintainers don't need to look at a function to see what it does, that's what its name tells you and keeping functions focused on doing one atomic thing is what allows the name to replace the implementation and makes for well written programs. I despise programs written in the style you suggest.
A well written program is a thousand small functions/methods unburdened by long methods full of comments. Good code requires few comments other than those that explain implementation choices or class responsibilities. Comments are a code smell most of the time, they exist to make up for poorly written code.
The problem isn't that these comments are harmful (they're not), but that inserting these comments made the coder feel like they'd done their job of commenting their code well, when in actuality the comments provide no insight to why certain things are called or instantiated, or what certain values represent; critical knowledge one needs to extend the code beyond the specific example cases the API guide presented.
----
‘ A for loop iterates through each row of DataGridView
For Each row In DirectCast(Me.DataGridView1.Rows, IEnumerable)
Dim frmTakeBackTask As New TakeBackTask
‘ Public oTaskData of TaskBackTask gets populated from the local object oTaskData
frmTakeBackTask.oTaskData = oTaskData
‘ A For loop is initiated to iterate through each child node contained
‘ in the XML document
For Each record In xmlDoc.ChildNodes.ItemOf(0).ChildNodes
‘ A nested For loop is initiated to iterate through each column
For Each column In record.ChildNodesMy beef with "increment the total" comments is not that they are there, but rather that they don't help me get the big picture.
That may be the only time that thought has gone through my head.
At my first internship, the code base had basically no comments in it, but was in general very clean, very organized, and there was a ton of thought put into naming and organization for readability. It was a good exercise for me working like that because it forced me to not rely on comments to explain messy code. But I also remember having long debates about what to name a variable to make it perfectly clear to the next person reading this code what it does (and often times ending up with excessively long variable names) and thinking "wow...this is a waste of time. You could just add a 1 line comment"
/* Gets the person's name
@returns the person's name */
public String getName() {
return name;
}
I've thought that every time I see a source file that contains an automatically generated header built from the revision history.