lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radim Kolar <...@filez.com>
Subject pro coding style
Date Thu, 29 Nov 2012 18:48:54 GMT
if you talk about my yesterday work then no reformats were done because 
code was already properly formatted. Also all code was hand written, no 
generated code was used. Generated code is not committed to git anyway.

my hard limits for code quality (checked at commit):
* no findbugs warnings with level 14+
* code coverage 80%
* code coverage in critical parts 95%
* list of PMD warnings to stop commit
* generation of call tree graph - check it for cycles, checking for 
calling same procedure from different levels (indicates bad code flow)
* all eclipse warnings turned into errors
* patched eclipse compiler to do better flow analysis
* code reformatted at commit
* javadoc everything, no warnings

what you should do:
* stuff i do
    +
* ant -> maven
* svn -> git (way better tools)
* split code into small manageable maven modules
* get more people
* put trust into your testing, not into perfect people
* work faster
* use github to track patches
* use springs for integration testing
* use jenkins to do tests on incoming patches
* do library checks for number of functions really used
* contributor patches should be high priority or you will lose contributors

i am giving sometimes lessons: about 1-2 sessions per year for 14 
people, if i have spare time. But its waste of time, most ppl will not 
follow.

learn this:
SLOW CODING != BUG FREE CODE.
GOOD TESTS + GOOD STATIC TESTING = GOOD BUG FREE CODE
CODE STYLE != GAME WITH SPACES AND { }
GOOD TESTS =  2x TIME NEEDED TO CODE STUFF UNDER TEST
GOOD TESTS ARE MORE VALUABLE THEN GOOD CODE

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message