[GRASS-dev] Code quality proposal

Hamish hamish_nospam at yahoo.com
Wed Aug 23 02:26:29 EDT 2006


Soeren Gebbert wrote:

> 2.) The code must pass the code quality assistant system without
> Monster and Clone warnings


For Monsters we should split analysis of library and module code, as
library code side skews the statistical def'n of a monster towards
something a few lines long.

A module will often do a task in a long sequential way; breaking that
up into smaller functions "just because" doesn't always improve the
quality or readability of the code IMO.

Automated QA systems (or gcc warnings) are very useful for spotting
potential problems in your code. I do support new code being tested with
it, I do not support a somewhat arbitrary quantification of a
qualitative problem having the final say over the inclusion of code or
not. In the end I think it will always take experienced human eyes to be
the final judge. CVS write access is given to a range of programming
talent; I know I rely on the "real" programmers to double check my work
sometimes. Committers should check the CVS-commit mailing list every now
and then & review one anothers work:
  http://grass.itc.it/pipermail/grass-commit/
and of course no one should commit code for someone else that they
haven't closely reviewed themselves.

(but QA & testing suites are still wonderfully useful tools)


2c,
Hamish




More information about the grass-dev mailing list