On Wed, Oct 13, 2010 at 6:18 AM, Thomas Koch <tho...@koch.ro> wrote: > I'd propose to have a word about quality assurance. Is there already a > strategy to ensure the ongoing maintainability of ZK? Is there a code style > guide, a list of Dos-And-Donts (where I'd like to add some points)? > > This wiki page has some of the detail you're looking for (code style, testing and such) http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute
> Should PMD be added to Hudson? What is the level of FindBugs? Should it be > raised? > It could be, but the issue I've seen with "add tool X" is that it really needs to be "add tool X, configure it reasonably, then hunt down all the issues you just found and require that ppl not introduce any going fwd, setup automated tests to enforce this going fwd". Other wise it becomes just another report that ppl ignore. We had similar issues with findbugs, until recently hadoop decided to make it a priority, everyone went "pencils down" for a few weeks and resolved all the issues. Also put guidelines in place (and automated testing) to ensure no new issues come in. It's a good idea. but not a panacea. > Some of the points I'd like to add to a style guide: > > - Don't write methods longer then 20-40 lines of code > > - Are you sure you want to use inner classes? > > - If there is a new operator in a method? Could the method maybe already > receive the object as a parameter? > > - Are you sure you want to use system properties? They are like global > variables and the IDE does not know about them > > - Are you sure you want to extend a class? Often an aggregation is more > elegant. > > - Don't nest ifs and loops deeper then 2 or 3 levels. If you do so, you > should > better break your code into more methods. > > - Use Enums or constants instead of plain status integers > > - please document your intentions in code comments. You don't need to > comment > the what? but the why?. > > Do you agree with me, that there is a need for better code quality in > ZooKeeper? If so, it's not really scalable if a manic like me fights like > Don > Quichotte to clean up the code. All developers would need to establish a > sense > for clean code and constantly improve the code. > I suspect we are in general agreement, however there are realities to be faced: 1) small team 2) semi-large existing codebase, lots of legacy in there. 3) existing user base Are we open to fixing things, yes.. Do we want to improve things, many in line with what you suggest, yes (ask mahadev, he/I talk about it frequently) But at the same time we can't break existing functionality, we don't like to destabilize the code (and what you are suggesting will cause instability) because then users really get upset. This netty set of changes is not helping things either. I suspect if we can get that out of the way it would help alot, allowing other refactorings to be done much more smoothly. Patrick > > [1] https://issues.apache.org/jira/browse/ZOOKEEPER-835 > > Best regards, > > Thomas Koch, http://www.koch.ro >
