Skip to content

Contributing to Treasury

lokka30 edited this page Dec 8, 2021 · 15 revisions

Page Information

Page Completion Valid as of Notes
🟢 80% v1.0.0 Need more guidelines added.

About

Treasury is a community project. Code contributions can help make Treasury better for every server owner and plugin utilizing the resource.

Contributions are done through pull requests on this GitHub repository.

All contributors are attributed for their work: in the code, and in documentation.

Things to Know

Please follow the Process below. We can't accept all contributions, as we maintain a high development standard for Treasury to keep it a great, stable resource. For example, we are strictly against bloating the resource, and we have a list of guidelines which PRs must follow in order to be merged. We always suggest you ask the Treasury maintainers first before starting work on any contributions to ensure it isn't a waste of time.

Process

  • Ask the Treasury maintainers if your contribution idea is worth working on
  • Fork Treasury's repository
  • Check the guidelines below, ensure you follow them throughout your code
  • Edit the fork by programming your ideas in
  • Push your commits to your fork's repository
  • Submit a pull request to Treasury's repository
  • Mark your pull request as a draft if it is not complete
  • Request the Treasury maintainers to review your pull request
  • Respond to feedback on your PR

Guidelines

Star imports

Don't use star imports - disable them in your IDE. For example, this is what not to do:

import org.bukkit.*;

Curly braces in if-else statements

For if-else statements, you must use curly braces ({ and }) in its structure. For example, this is what not to do:

if(shouldDoSomething)
  doSomething();
else
  dontDoSomething();

Starting curly braces on the same line

With very few exceptions, starting curly braces should not be on its own line. For example, this is what you should do:

if(true) {
  hello();
}

This is what you should not do:

if(true)
{
  hello();
}

Automatic refactoring

Do not blindly allow your IDE to automatically fix warnings in the resource. Some things are meant to be but your IDE will complain about it, such as config variables which are not final on purpose.

Do not use Reformat Code or Rearrange Code in IntelliJ! (Or equivalent in other IDEs.) Definitely use Optimize Imports if you're sure it's choosing the correct imports (check before you commit).

Is that all!?

Not really - it's unfeasible for us to cover every single thing, so we're adding entries as we spot them. So long you're using common sense + standard Java programming principles such as camelCase for method names etc, there is a very low chance your code will have any problems here.