[GRASS-dev] Code quality proposal

[Glynn Clements]

Hamish 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)

I don't have time to review everything that goes into GRASS (and I
don't subscribe to the commit list for this reason). An automated tool
might be useful if it can highlight specific commits as worthwhile
subjects for investigation.

-- 
Glynn Clements <glynn at gclements.plus.com>