Development Guidelines
In order to maintain a high level of code quality and improve the efficiency for other developers to verify your code, we have established the following guidelines for contributing to the project.
Coding Standards
Where possible, write unit tests for your code (see Testing and Debugging). This will help to ensure that your code is correct, and will help to prevent regressions in the future. Also include edge cases in your tests.
Use atomic commits. Each commit should be a single logical change. Don’t make several logical changes in one commit. For example, if a patch fixes a bug and optimizes the performance of a feature, it should be split into two separate commits.
Commit messages should be clear, concise, and useful. The first line should be a short description of the commit, then a blank line, then a more detailed explanation. The commit message should be in the present tense. For example, “Fix bug” and not “Fixed bug”.
If applicable, include a reference to the issue that the commit addresses. For example, if you’re working on a fix for GitHub issue #123, then format your commit message like this: “[#123] Fix bug”. This makes it easier to track which commits are associated with which issues.
Pull Request Process
When submitting a pull request to the OpenRocket repository, please follow these guidelines:
Fork the Repository: Start by forking the OpenRocket repository to your own GitHub account.
Create a Branch: Create a branch in your fork for your changes. Use a descriptive name that reflects the purpose of your changes.
Make Your Changes: Implement your changes following the coding standards described above.
Test Your Changes: Make sure your changes work as expected and don’t break existing functionality. Run the relevant tests.
Submit a Pull Request: When you’re ready, submit a pull request from your branch to the OpenRocket repository.
Describe Your Changes: In the pull request description, provide a clear explanation of what your changes do and why they are needed. Reference any related issues.
Review Process: Be prepared to respond to feedback and make changes if requested by the maintainers.
Continuous Integration: The pull request will be automatically tested by the CI system. Make sure all tests pass.
Merge: Once your pull request is approved, it will be merged into the main codebase.
Code Style
OpenRocket follows these code style guidelines:
Indentation: Use 4 spaces for indentation, not tabs.
Line Length: Try to keep lines under 120 characters.
Naming Conventions: - Classes: Use PascalCase (e.g., RocketComponent) - Methods and variables: Use camelCase (e.g., getAltitude()) - Constants: Use UPPER_SNAKE_CASE (e.g., MAX_ALTITUDE)
Comments: Use Javadoc comments for classes, methods, and fields. Include descriptions, parameter explanations, return value descriptions, and exception information.
/** * Calculates the apogee of the rocket. * * @param simulation The simulation to use for the calculation * @return The apogee altitude in meters * @throws SimulationException If the simulation fails */ public double calculateApogee(Simulation simulation) throws SimulationException { // Implementation }
Imports: Organize imports and avoid wildcard imports.
Exception Handling: Always handle or propagate exceptions appropriately. Don’t catch exceptions without proper handling.
Resource Management: Always close resources (files, streams, etc.) in a finally block or use try-with-resources.
Documentation Guidelines
When adding or modifying code, please follow these documentation guidelines:
Javadoc: Add Javadoc comments to all public classes, methods, and fields.
Code Comments: Add inline comments to explain complex or non-obvious code.
User Documentation: Update the user documentation if your changes affect user-facing features.
Developer Documentation: Update the developer documentation (like this guide) if your changes affect the development process or API.
Examples: Provide examples for new features or APIs.
Checkstyle
OpenRocket uses Checkstyle to enforce code style rules. You can run Checkstyle with:
./gradlew checkstyleMain checkstyleTest
Fix any Checkstyle violations before submitting your pull request.