[GRASS-dev] Code quality proposal

[Sören Gebbert]

Dear Hamish,

Hamish schrieb:
> 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.

I agree.

> 
> 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.

Yes, not always but in my opinion very often. If a long sequence is
split in shorter logical and meaningful functions, the code will be much 
more readable and understandable.
This requires of course long programming practice and a good 
understanding of the code and how to organize it.

But i think we should orient the coding of grass on such principles.
Of course there will be cases where a long code sequence is needed,
but this should be an exception and not the rule.
This effort will be repay in the long term.
If the code of the modules is better readable and easier to understand,
bugfixing and improvements are much easier to implement.
And new developers will have more good examples how to code in grass.

And we can start to ensure these principles by checking new
module contributions and encourage the developers to fulfil those
principles. (bevor submitting this code to CVS)
This process can be started if new modules for grass
are discussed on the list? And the devs (including hopefully me) will 
have a look
at the code. In addition the QA will be a help to have an orientation 
about the code quality.

I think that can be handled, because there are not so much new 
contributions of new modules. :)

The bigger problem is to treat the existing code to fulfil such standards.

> 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

I think its not that arbitrary.

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

Indeed.

Best regards
Soeren

> 
> 
> 2c,
> Hamish
> 
>