Skip to main content
Code Review

Return to Answer

Commonmark migration
Source Link

##About Comments in general

About Comments in general

##About Comments in general

About Comments in general

  1. youYou have not commented enough.
  2. youYou have commented all the wrong things.
  3. youYou have commented too much.
  4. yourYour comments are in the wrong format.
  5. youYou are missing the formal comments.

letLet me say that again.:

Good code seldom needs comments.

  1. commentsComments make plain what the code does not tell us already.
  2. goodGood code seldom needs comments.
  1. goodGood code seldom needs comments.
  2. goodGood code must make plain what the code does without the need for additional explanation.
  1. you have not commented enough
  2. you have commented all the wrong things
  3. you have commented too much.
  4. your comments are in the wrong format
  5. you are missing the formal comments.

let me say that again.

Good code seldom needs comments

  1. comments make plain what the code does not tell us already
  2. good code seldom needs comments
  1. good code seldom needs comments
  2. good code must make plain what the code does without the need for additional explanation.
  1. You have not commented enough.
  2. You have commented all the wrong things.
  3. You have commented too much.
  4. Your comments are in the wrong format.
  5. You are missing the formal comments.

Let me say that again:

Good code seldom needs comments.

  1. Comments make plain what the code does not tell us already.
  2. Good code seldom needs comments.
  1. Good code seldom needs comments.
  2. Good code must make plain what the code does without the need for additional explanation.
Bounty Awarded with 100 reputation awarded by h.j.k.
typos
Source Link
rolfl
  • 98.1k
  • 17
  • 219
  • 419

Bottom line, though, is that the comments in your code should fill in the blanks that your code does not. In addition, your comments should give details on the motivation, and not the application of your code. You should, ingeneralin general, comment only on why your code does things, not what your code is doing.

You have no JavaDoc, and you likelyelikely should. JavaDoc is where you describe what your code does, because, typically, the people reading the javadoc are not reading the code, so they need something else to tell them what the code does.

Bottom line, though, is that the comments in your code should fill in the blanks that your code does not. In addition, your comments should give details on the motivation, and not the application of your code. You should, ingeneral, comment only on why your code does things, not what your code is doing.

You have no JavaDoc, and you likelye should. JavaDoc is where you describe what your code does, because, typically, the people reading the javadoc are not reading the code, so they need something else to tell them what the code does.

Bottom line, though, is that the comments in your code should fill in the blanks that your code does not. In addition, your comments should give details on the motivation, and not the application of your code. You should, in general, comment only on why your code does things, not what your code is doing.

You have no JavaDoc, and you likely should. JavaDoc is where you describe what your code does, because, typically, the people reading the javadoc are not reading the code, so they need something else to tell them what the code does.

Formatting, negative sense on win condition
Source Link
rolfl
  • 98.1k
  • 17
  • 219
  • 419
Loading
Source Link
rolfl
  • 98.1k
  • 17
  • 219
  • 419
Loading
lang-java

AltStyle によって変換されたページ (->オリジナル) /