Skip to main content
clarification
Source Link
amon
  • 12.7k
  • 14
  • 23

A source file has two audiences:

  1. The compiler, for which we have to write working code. This is of no interest on Code Review, as all code is supposed to be already working.
  2. A human reader, for which we format our code, think about good naming, and explain our code via comments. Documentation falls into this category.

For example, a review of this source snippet:

/** Frobnicate the object
  *
  * Returns a frobnicated copy
  */
public SomeClass frobnicate() {
    ....
}

Could be reviewed like

You could use the @return directive for the return value. Also, The documentation is just stating the same thing as the type signature, and is therefore of little use. You could explain what frobnication means in the context of your project. You should also mention that an InvalidFrobnicationException will be thrown if this.frobnicator is null.

However, such reference documentation is just a small subset of possible documentation – tutorials and guides would certainly not be on topic here, as the quality of writing and not the source code of the implementation is the main concern.

For questions about writing documentation, Writers or Programmers might be a better fit, depending on the focus of the question. Reviews here on Code Review can (and should) also touch upon documentation, but the docs shouldn't be the main focus: docs are an important part of the source, but they are not code.

A source file has two audiences:

  1. The compiler, for which we have to write working code. This is of no interest on Code Review.
  2. A human reader, for which we format our code, think about good naming, and explain our code via comments. Documentation falls into this category.

For example, a review of this source snippet:

/** Frobnicate the object
  *
  * Returns a frobnicated copy
  */
public SomeClass frobnicate() {
    ....
}

Could be reviewed like

You could use the @return directive for the return value. Also, The documentation is just stating the same thing as the type signature, and is therefore of little use. You could explain what frobnication means in the context of your project. You should also mention that an InvalidFrobnicationException will be thrown if this.frobnicator is null.

However, such reference documentation is just a small subset of possible documentation – tutorials and guides would certainly not be on topic here, as the quality of writing and not the source code of the implementation is the main concern.

For questions about writing documentation, Writers or Programmers might be a better fit, depending on the focus of the question. Reviews here on Code Review can (and should) also touch upon documentation, but the docs shouldn't be the main focus: docs are an important part of the source, but they are not code.

A source file has two audiences:

  1. The compiler, for which we have to write working code. This is of no interest on Code Review, as all code is supposed to be already working.
  2. A human reader, for which we format our code, think about good naming, and explain our code via comments. Documentation falls into this category.

For example, a review of this source snippet:

/** Frobnicate the object
  *
  * Returns a frobnicated copy
  */
public SomeClass frobnicate() {
    ....
}

Could be reviewed like

You could use the @return directive for the return value. Also, The documentation is just stating the same thing as the type signature, and is therefore of little use. You could explain what frobnication means in the context of your project. You should also mention that an InvalidFrobnicationException will be thrown if this.frobnicator is null.

However, such reference documentation is just a small subset of possible documentation – tutorials and guides would certainly not be on topic here, as the quality of writing and not the source code of the implementation is the main concern.

For questions about writing documentation, Writers or Programmers might be a better fit, depending on the focus of the question. Reviews here on Code Review can (and should) also touch upon documentation, but the docs shouldn't be the main focus: docs are an important part of the source, but they are not code.

Source Link
amon
  • 12.7k
  • 14
  • 23

A source file has two audiences:

  1. The compiler, for which we have to write working code. This is of no interest on Code Review.
  2. A human reader, for which we format our code, think about good naming, and explain our code via comments. Documentation falls into this category.

For example, a review of this source snippet:

/** Frobnicate the object
  *
  * Returns a frobnicated copy
  */
public SomeClass frobnicate() {
    ....
}

Could be reviewed like

You could use the @return directive for the return value. Also, The documentation is just stating the same thing as the type signature, and is therefore of little use. You could explain what frobnication means in the context of your project. You should also mention that an InvalidFrobnicationException will be thrown if this.frobnicator is null.

However, such reference documentation is just a small subset of possible documentation – tutorials and guides would certainly not be on topic here, as the quality of writing and not the source code of the implementation is the main concern.

For questions about writing documentation, Writers or Programmers might be a better fit, depending on the focus of the question. Reviews here on Code Review can (and should) also touch upon documentation, but the docs shouldn't be the main focus: docs are an important part of the source, but they are not code.