hey,
some comments inline...
On Thu, Nov 29, 2012 at 7:48 PM, Radim Kolar <h...@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-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
