lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Willnauer <simon.willna...@gmail.com>
Subject Re: pro coding style
Date Thu, 29 Nov 2012 21:37:45 GMT
hey,

some comments inline...

On Thu, Nov 29, 2012 at 7:48 PM, Radim Kolar <hsn@filez.com> wrote:
> 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

I suggest you start with this, make sure you have enough time and
energy for the discussion.

> * svn -> git (way better tools)

I think we had this discussion already and it seems that lots of folks
are positive, yet there is still some barrier infrasturcuture wise
along the lines.
> * split code into small manageable maven modules
see above - we have a fully functional maven build but ant is out
primary build. My honest opinion forget what I said above - don't try.
> * get more people
good point - can you refere us some, in my experience they are pretty
hard to find.

> * put trust into your testing, not into perfect people

ahh yeah testing, we should do that at some point

> * work faster

wow - I never thought about that though!
> * use github to track patches

wait why is github good for patches?

> * use springs for integration testing

sorry we are a no-dependency library.

> * use jenkins to do tests on incoming patches

patches welcome

> * do library checks for number of functions really used

hmm - we are a library?

> * contributor patches should be high priority or you will lose contributors

thats is a good advice for such a young project.
>
> 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

lets drop the code its a hassle to maintain anyway!

thanks man,

this mail made my day!

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

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


Mime
View raw message