Skip to content

Commit 7f85c2a

Browse files
committed
Add Good comments section chapter 4
1 parent d23e1c6 commit 7f85c2a

File tree

1 file changed

+94
-0
lines changed

1 file changed

+94
-0
lines changed

README.md

Lines changed: 94 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -359,3 +359,97 @@ Nothing can be quite so helpful as a well-placed comment. Nothing can clutter up
359359
If our programming languages were expressive enough, or if we had the talent to subtly wield those languages to express our intent, we would not need comments very much—perhaps not at all.
360360

361361
### Comments Do Not Make Up for Bad Code
362+
Clear and expressive code with few comments is far superior to cluttered and complex code with lots of comments. Rather than spend your time writing the comments that explain the mess you’ve made, spend it cleaning that mess.
363+
364+
### Explain Yourself in Code
365+
```java
366+
// Check to see if the employee is eligible for full benefits
367+
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))
368+
```
369+
370+
vs
371+
372+
```java
373+
if (employee.isEligibleForFullBenefits())
374+
```
375+
376+
### Good Comments
377+
Some comments are necessary or beneficial. However the only truly good comment is the comment you found a way not to write.
378+
379+
#### Legal Comments
380+
Sometimes our corporate coding standards force us to write certain comments for legal reasons. For example, copyright and authorship statements are necessary and reasonable things to put into a comment at the start of each source file.
381+
382+
#### Informative Comments
383+
It is sometimes useful to provide basic information with a comment. For example, consider this comment that explains the return value of an abstract method:
384+
385+
```java
386+
// Returns an instance of the Responder being tested.
387+
protected abstract Responder responderInstance();
388+
```
389+
390+
A comment like this can sometimes be useful, but it is better to use the name of the function to convey the information where possible. For example, in this case the comment could be made redundant by renaming the function: `responderBeingTested`.
391+
392+
#### Explanation of Intent
393+
Sometimes a comment goes beyond just useful information about the implementation and provides the intent behind a decision. Example:
394+
395+
```java
396+
public int compareTo(Object o)
397+
{
398+
if(o instanceof WikiPagePath)
399+
{
400+
WikiPagePath p = (WikiPagePath) o;
401+
String compressedName = StringUtil.join(names, "");
402+
String compressedArgumentName = StringUtil.join(p.names, "");
403+
return compressedName.compareTo(compressedArgumentName);
404+
}
405+
return 1; // we are greater because we are the right type.
406+
}
407+
```
408+
#### Clarification
409+
410+
Sometimes it is just helpful to translate the meaning of some obscure argument or return value into something that’s readable. In general it is better to find a way to make that argument or return value clear in its own right; but when its part of the standard library, or in code that you cannot alter, then a helpful clarifying comment can be useful.
411+
412+
#### Warning of concequences
413+
Sometimes it is useful to warn other programmers about certain consequences.
414+
415+
```java
416+
// Don't run unless you
417+
// have some time to kill.
418+
public void _testWithReallyBigFile() {
419+
writeLinesToFile(10000000);
420+
response.setBody(testFile);
421+
response.readyToSend(this);
422+
String responseString = output.toString();
423+
assertSubString("Content-Length: 1000000000", responseString);
424+
assertTrue(bytesSent > 1000000000);
425+
}
426+
```
427+
#### TODO Comments
428+
It is sometimes reasonable to leave “To do” notes in the form of //TODO comments. In the
429+
following case, the TODO comment explains why the function has a degenerate implementation and what that function’s future should be.
430+
```java
431+
//TODO-MdM these are not needed
432+
// We expect this to go away when we do the checkout model
433+
protected VersionInfo makeVersion() throws Exception {
434+
return null;
435+
}
436+
```
437+
438+
TODO s are jobs that the programmer thinks should be done, but for some reason can’t do at the moment. It might be a reminder to delete a deprecated feature or a plea for someone else to look at a problem. It might be a request for someone else to think of a better name or a reminder to make a change that is dependent on a planned event. Whatever else a TODO might be, it is not an excuse to leave bad code in the system.
439+
440+
#### Amplification
441+
A comment may be used to amplify the importance of something that may otherwise seem inconsequential.
442+
443+
```java
444+
String listItemContent = match.group(3).trim();
445+
// the trim is real important. It removes the starting
446+
// spaces that could cause the item to be recognized
447+
// as another list.
448+
new ListItemWidget(this, listItemContent, this.level + 1);
449+
return buildList(text.substring(match.end()));
450+
```
451+
452+
#### Javadocs in Public APIs
453+
There is nothing quite so helpful and satisfying as a well-described public API. The javadocs for the standard Java library are a case in point. It would be difficult, at best, to write Java programs without them.
454+
455+

0 commit comments

Comments
 (0)