harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Qiu" <sean.xx....@gmail.com>
Subject Re: [general] How to be a good contributor?
Date Fri, 25 Apr 2008 03:15:52 GMT
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 <aleksey.shipilev@gmail.com>:
> 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

Mime
View raw message