You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+94Lines changed: 94 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -359,3 +359,97 @@ Nothing can be quite so helpful as a well-placed comment. Nothing can clutter up
359
359
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.
360
360
361
361
### 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
+
protectedabstractResponder 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:
return1; // 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.
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
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.
0 commit comments