Subscribe to PHP Freaks RSS

More code comments

syndicated from planet-php.net on August 13, 2018

Recently I read a comment on Twitter by Nicola Poša:





He was providing us with a useful suggestion, one that I myself have been following ever since reading "Clean Code" by Robert Martin. The paraphrased suggestion in that book, as well as in the tweet, is to consider a comment to be a naming issue in disguise, and to solve that issue, instead of keeping the comment. By the way, the book has some very nice examples of how comments should and should not be used.



Comments as a naming issue



I think in most cases, indeed, we don't need comments. Common suggestions are, like Nicola suggests as well:



  • Introduce a variable with a meaningful name, which can hold the result of a complicated expression.
  • Introduce a method with a meaningful name, which can hide a piece of complicated logic.

The "hiding" that a method does, provides you with two interesting options:



  1. The method name can summarize a number of statements.
  2. The method name can represent a concept that is of a higher level than the lower-level things that are going on inside the method.

Option 1 is useful, but if you can go for option 2, it'll be the most valuable option.



Consider Nicola's example:



if ($date->hour < 9 || $date->hour > 17) { //Off-hours?
}


Option 1 would entail something like:



if ($this->hourIsBetween9And17($date->hour)) { //Off-hours?
}


Option 2 would be much more interesting and useful:



if ($this->isAnOffHour($date->hour)) {
}


This introduces abstraction, where the client doesn't care about the concrete details of determining whether or not a certain hour is an off-hour, but only wants to know if the given hour is indeed an off-hour.



#NoComments?



I realized I'm always applying the following rule: if I feel like writing a comment, I look for a way in which I can change the code so that I don't have to write a comment anymore. Also, when I encounter a comment in an existing code base, I apply the same rule, and look for ways to remove the comment. Because, as you may know, code can't lie, but comments can, so let's get rid of them before they become a risk.



However, contrary to my own advise, I also realized that I've actually been writing more and more comments over the past few months. So what's going on?



A little soul-searching revealed that I've been adding code comments that can be categorized as follows:



  1. Explanatory comments: ~70%
  2. TODO comments: ~20%
  3. WTF comments: ~10%

Explanatory comments



I've been adding explanatory comments to parts in the code that need an explanation, or a canonical description of the situation. Most often these comments can be found near a couple of statements in the domain model. The comment then explains why a certain business rule should be applied, and how the code beneath the comment actually accomplishes this. Of course, I try to match the words in the comment with the words in the code itself, so they are tied together.



Before adding an explanatory comment, I often try to rephrase the explanation as a test first. This is usually the better option, since it will make sure that the code and its documentation will never diverge. The test is the documentation that describes a piece of the code, and if the code is no longer truthful to that description, the test will fail. An even better option is to apply behavior-driven development, where tests can actually be written as stories with examples, and they will serve as automated tests at the same time.



Still, some things just need a whole paragraph of explaining, and in that case, I happily put the explanation in the code, and take my time (and a long-form commenting style like /* ... */) to explain what's going on.



"Here's a question: why don't you create a separate document, instead of a code comment?"



Good question; i

Truncated by Planet PHP, read more at the original (another 4676 bytes)