Maybe you can involve some coding convention tools to help you find out many "trivial" but important issues. Checkstyle[1] is a good candidate, and it has many IDE plugins[2] which is easy to use. PMD is another good candidate, but i have not try it yet.
We'd better always keep these conventions in our minds. These tools may help us to make them a kind of our instinct. [1] http://checkstyle.sourceforge.net [2] http://eclipse-cs.sourceforge.net/basic_creating_config.html [3] http://pmd.sourceforge.net/ 2008/4/24 Aleksey Shipilev <[EMAIL PROTECTED]>: > Hi Alexey (Petrenko), Nathan, Mark, all! > > Thanks for supporting me in creating the good patches against Harmony! > I had read "Good Issue Resolution Guideline" [1] and "Bad Smells" [2]. > I will struggle to comply with them further. But also I need to know > the answers on topics which are not covered by the docs. I have my own > answers on them, but it would be great to see if my perception is what > Harmony committers expect. > > 1. Coding conventions. What coding convention Harmony is using? Is it > common "Code Conventions for the Java" [3]? > > 2. Patch separation. I see that there is an requirement in place to > divide test and implementation parts into distinct patches. Does that > apply to formatting, documentation and > text-reordering patches? I guess, it does. > > 3. Explaining what the patch does. To what extent should one describe > what exactly the patch does: should it be the "investigation path" > which lead to fix, short description of fundamental changes, the > reason why this exact solution is better? I think that short > description on each change in patch should be enough. > > 4. Proof-of-concept patches. Is it acceptable to have POC patches > attached to JIRA if there's distinct reminder that the patch is > prototype and is not supposed to be committed? Personally I like to > attach the "checkpoint patches" to JIRA when I'm working on issues, > 'cause this could minimize the efforts on continuing works in case of > something happens with my computer or me :) > > I think the answers on these questions worth publishing in resolution > guideline or similar document. > > Is there anything else to read about good coding practices? > > Thanks! > Aleksey. > > [1] http://harmony.apache.org/issue_resolution_guideline.html > [2] http://sis36.berkeley.edu/projects/streek/agile/bad-smells-in-code.html > [3] http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html > -- Best Regards Sean, Xiao Xia Qiu China Software Development Lab, IBM
