Skip to content

Latest commit

 

History

History
54 lines (41 loc) · 2.49 KB

CONTRIBUTING.md

File metadata and controls

54 lines (41 loc) · 2.49 KB

Contributing Guidelines

Thanks for your interest in opsu! This document provides basic guidelines for contributing to the repository. If you plan on making major changes, consider opening an issue first to discuss your ideas.

Making a Change

  1. Fork the repository and set up your build environment, as described in the README.
  2. Make your desired code changes in your fork.
  3. Test your change. There are no automated tests, so just do this manually. Read the testing tips below for some suggestions.
  4. Commit your change and create a pull request. Follow up with any requested changes as needed.

Guidelines

  • A pull request should only contain one feature or bug fix. If you want to make multiple changes, create branches and open separate pull requests.
  • Don't change more than you need to. In particular, don't change the coding style or move existing blocks around.
  • In general, follow the same coding style as the file that you're editing.
  • Write comments in your code as needed. At minimum, Javadoc comments are expected on all classes, methods, and global variables.

Coding Style

  • If you use IntelliJ IDEA, project-provided settings (e.g. code style) must be used.
  • Also if you use IntelliJ IDEA, then you shall reformat your java files with built-in Code -> Reformat Code (Ctrl+Alt+L by default).
  • If you edit someone else's file, follow the same coding style as the file being edited.
  • Spaces should be used for indenting.
  • There is no maximum line length; break long lines (or not) for readability.
  • Java 8 features (e.g. streams, lambdas) are allowed as far as they are not cause any errors in runtime.

Testing Tips

  • Gameplay changes: Depending on the change, consider playing through a regular or 2B beatmap, watching a replay, pausing/resuming the game, enabling/disabling experimental sliders, etc.
  • UI changes: Be sure to try different client resolutions (such as 800x600 and widescreen) and different skins (if applicable).
  • Graphics/audio changes: Test on different operating systems if you can, especially if your change could break Linux audio in any way.