Letters from Readers
Letters From Readers
In January, On VB columnist Joe Kunk wrote a column entitled "To Comment or Not to Comment." This article evoked some spirited debate about the costs and benefits of commenting code. Most respondents vigorously supported commenting, but a few offered a counter argument.
Comments are a clue as to what the developer was thinking when he wrote the comment. As long as you keep that in mind, comments are useful to have. But I'd rather not duplicate info in a comment that's already evident in the code. Sparse, value-added comments are good. Comments for the sake of comments are bad!
Arnold
Rolling Meadows, Ill.
I've seen places where comments have been useful: for example, if you change code in a way that looks obvious but something unexpected will happen. However, in general, comments clutter the code that's written by experts for experts to read. My guess is that for every time a comment has added to my understanding, there have been an equal number of comments that clouded my knowledge of what was actually going on. I almost never read the comments until I have an understanding of what the code is doing.
Garth
New Zealand
While no one can be completely against comments, I kind of fall into the anti-comment camp. I'm a Smalltalk programmer and, to my mind, most Smalltalk code typically has too few comments -- where too few means practically none. But in Smalltalk we (mostly) get away with this because Smalltalk is a good-quality object-oriented language and object-oriented languages tend to result in more readable code. Also, Smalltalk uses named method parameters. Named method parameters make code much easier to follow and make comments much less necessary. I've never understood why most of the object-oriented languages that came after Smalltalk abandoned named parameters in favor of C-style argument lists.
Ralph
Calgary, Alberta, Canada
About the Author
This story was written or compiled based on feedback from the readers of Visual Studio Magazine.