2012-10-26 02:45:04 +08:00
|
|
|
Contributing
|
|
|
|
============
|
|
|
|
|
|
|
|
Thank you for your interest in contributing to WorldEdit! We appreciate your
|
2012-10-29 02:08:31 +08:00
|
|
|
effort, but to make sure that the inclusion of your patch is a smooth process, we
|
|
|
|
ask that you make note of the following guidelines.
|
2012-10-26 02:45:04 +08:00
|
|
|
|
2024-06-11 12:57:04 +08:00
|
|
|
* **Target Java 21 for source and compilation.** Make sure to mark methods with
|
2012-10-26 02:45:04 +08:00
|
|
|
` @Override` that override methods of parent classes, or that implement
|
2016-12-03 12:27:46 +08:00
|
|
|
methods of interfaces.
|
2012-10-26 02:45:04 +08:00
|
|
|
* **Use only spaces for indentation.** Our indents are 4-spaces long, and tabs
|
|
|
|
are unacceptable.
|
2014-04-06 10:33:05 +08:00
|
|
|
* **Wrap code to a 120 column limit.** We do this to make side by side diffs
|
2012-10-26 02:45:04 +08:00
|
|
|
and other such tasks easier. Ignore this guideline if it makes the code
|
|
|
|
too unreadable.
|
|
|
|
* **Write complete Javadocs.** Do so only for public methods, and make sure
|
|
|
|
that your `@param` and `@return` fields are not just blank.
|
|
|
|
* **Don't tag classes with @author.** Some legacy classes may have this tag,
|
|
|
|
but we are phasing it out.
|
|
|
|
* **Make sure the code is efficient.** One way you can achieve this is to spend
|
|
|
|
around ten minutes to think about what the code is doing and whether it
|
|
|
|
seems awfully roundabout. If you had to copy the same large piece of
|
|
|
|
code in several places, that's bad.
|
|
|
|
* **Keep commit summaries under 70 characters.** For more details, place two
|
|
|
|
new lines after the summary line and write away!
|
|
|
|
* **Test your code.** We're not interested in broken code, for the obvious reasons.
|
|
|
|
* **Write unit tests.** While this is strictly optional, we recommend it for
|
|
|
|
complicated algorithms.
|
|
|
|
|
|
|
|
|
2020-12-12 04:53:54 +08:00
|
|
|
Additional Notes
|
|
|
|
----------------
|
|
|
|
If you're submitting a feature, base your code on `master` and PR against the
|
|
|
|
`master` branch. If you're submitting a bugfix, base your code on the newest
|
|
|
|
`version/*` branch, and PR against that same branch.
|
|
|
|
|
|
|
|
|
2012-10-26 02:45:04 +08:00
|
|
|
Checklist
|
|
|
|
---------
|
|
|
|
|
|
|
|
Ready to submit? Perform the checklist below:
|
|
|
|
|
|
|
|
1. Have all tabs been replaced into four spaces? Are indentations 4-space wide?
|
|
|
|
2. Have I written proper Javadocs for my public methods? Are the @param and
|
|
|
|
@return fields actually filled out?
|
|
|
|
3. Have I `git rebase`d my pull request to the latest commit of the target
|
|
|
|
branch?
|
|
|
|
4. Have I combined my commits into a reasonably small number (if not one)
|
|
|
|
commit using `git rebase`?
|
|
|
|
5. Have I made my pull request too large? Pull requests should introduce
|
|
|
|
small sets of changes at a time. Major changes should be discussed with
|
|
|
|
the team prior to starting work.
|
|
|
|
6. Are my commit messages descriptive?
|
|
|
|
|
2021-04-29 05:15:12 +08:00
|
|
|
You should be aware of [`git rebase`](https://docs.github.com/github/getting-started-with-github/about-git-rebase).
|
2012-10-26 02:45:04 +08:00
|
|
|
It allows you to modify existing commit messages, and combine, break apart, or
|
|
|
|
adjust past changes.
|
|
|
|
|
|
|
|
Example
|
|
|
|
-------
|
|
|
|
|
|
|
|
This is **GOOD:**
|
|
|
|
|
|
|
|
if (var.func(param1, param2)) {
|
|
|
|
// do things
|
|
|
|
}
|
|
|
|
|
|
|
|
This is **EXTREMELY BAD:**
|
|
|
|
|
|
|
|
if(var.func( param1, param2 ))
|
|
|
|
{
|
|
|
|
// do things
|
|
|
|
}
|