Documentation

The Grade System

Inch evaluates inline-docs and reports grades for each class, module and method.

Philosophy

Inch was created to help people document their code, therefore it may be more important to look at what it does not do than at what it does.

  • It does not aim for "fully documented" or "100% documentation coverage".
  • It does not tell you to document everything (neither does it tell you not to).
  • It does not impose rules on how your documentation should look like.
  • It does not require that, e.g."every function's documentation should be a single line under 80 characters not ending in a period" or that "every class and module should provide a code example of their usage".

Inch takes a more relaxed approach towards documentation measurement and tries to show you places where your codebase could use more documentation.

The Grade System

Inch assigns grades to each class, module, constant or function in a codebase, based on how complete the docs are.

The grades are:

  • A - Seems really good
  • B - Properly documented, but could be improved
  • C - Needs work
  • U - Undocumented

Using this system has some advantages compared to plain coverage scores:

  • You can get an A even if you "only" get 90 out of 100 possible points.
  • Getting a B is basically good enough.
  • Undocumented objects are assigned a special grade, instead of scoring 0%.

The last point might be the most important one: If objects are undocumented, there is nothing to evaluate. Therefore you can not simply give them a bad rating, because they might be left undocumented intentionally.

Inch does not give you a grade for your whole codebase. The grade distribution does a much better job of painting the bigger picture.

Priorities ↑ ↓

Every class, module and function in a codebase is assigned a priority which reflects how important Inch thinks it is to be documented.

This process follows some reasonable rules, like

  • it is more important to document public functions than private ones
  • it is more important to document functions with many parameters than functions without parameters
  • it is not important to document objects marked as private

Priorities are displayed as arrows. Arrows pointing north mark high priority objects, arrows pointing south mark low priority objects.