Hey Antonio,
Am Sonntag, den 14.01.2018, 09:07 +0100 schrieb Antonio:
>
> I started some PR coding best practices at [1].
>
>
> [1]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=7468
> 1408#SubmittingPullRequestonApacheNetbeans(incubating)-
> PRCodingBestPractices
Thank you for starting this. This is my suggestion, as it collides with
the wiki version, I did not change it directly:
----------------------------------------------------------------------
Contribution Guidelines
=======================
1. All commits must include the authors full name and email address
2. All commits must contain a meaningful commit message. A meaningful
commit message holds in the first line a summary of the commit and
in the body (beginning on the third-line) an explanation what was
changed and why it was done. Remember here, that the future this
commit message is most probably the only source of information why a
change was commited to the code base.
3. If the commit fixes a reported issue, the summary line should hold
the issue number and title "[NETBEANS-XXX] Maven pom.xml file
corrupted after inserting dependecies" for example.
4. A PR can consist of multiple commits. These commits should group the
changes into meaningful entities. Fixup commits should be squashed
into the base commit they fix.
5. For contributers: Be prepared to be asked questions about your PR. A
reviewer might have questions and you should be able to answer why
you did a fix in a certain way and why it is save and appropriate.
Remember that the review sometimes takes as long, as creating a
patch in the first place. Good commit messages help as the
anticipate questions.
6. For reviewers: Keep in mind that the contributor wants to fix a
problem and put effort into it. So be polite and focused.
7. Don't change code, that is correct and works. Consider a simple
loop. In many cases you can switch between for-loop, for-each-loop
and stream construct. All are valid solution, don't change the code
if it is not broken. An improvement is a different case. For example
a try-with-resource construct is in general more correct, than the
try-finally construct many developers fail to implement correctly.
Constructs leading to warnings from the javac are also good
candidates for simple fixes.
8. Run unittests and, if you introduce new feature/fixes, add
unittests. So before you start your work, check that unittests for
the module you are working on run correctly and after you are done
still do. If unittests fail, fixing these would be good addition to
the codebase (it would be good to use a separate commit for this)
9. Keep your PRs up-to-date. When the PR can't be merged directly, it
can happen, that changes are introduced into the codebase, that
conflict with your PR, you should then update it accordingly.
10. Follow the coding conventions of the file. Your code should match
that style and not stand out. For new files, please follow the code
conventions for the netbeans code base: https://netbeans.org/communi
ty/guidelines/code-conventions.html
And remember: These are guidelines, not laws.
----------------------------------------------------------------------
For me above can be summarized as: "Use common sense". I deliberately
did not go to deep into details to keep it simple, but complete enough.
There are still areas where personal preferences come in, for example I
don't agree with the given sample for the diamond operator.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
