Code Style Guidelines
Adhering to a consistent code style helps maintain readability and eases collaboration. Here are the guidelines you should follow when contributing to POSYDON.
General Principles
Clarity and Readability: Code should be easy to understand. Opt for clarity over cleverness.
Consistency: Follow the style of the existing codebase. When in doubt, consistency with the existing code is more important than adhering to external style guides.
Comments: Write meaningful comments, especially for complex logic. Avoid obvious comments.
Python Style Guide
We follow the PEP 8 style guide for Python code with some exceptions and additions as outlined below.
Indentation: Use 4 spaces per indentation level.
Line Length: Limit lines to 79 characters.
Imports: Group imports in the following order: standard libraries, third-party libraries, and local application imports. Each group should be separated by a blank line.
- Whitespace: Avoid extraneous whitespace in the following situations:
Immediately inside parentheses, brackets, or braces.
Immediately before a comma, colon, or semicolon.
Comments: Comments should be complete sentences and should be used sparingly, i.e., only when necessary to explain complex pieces of logic or decisions that could seem non-obvious to other developers.
Naming Conventions
Functions and Variables: Use snake_case.
Classes and Exceptions: Use CamelCase.
Constants: Use UPPER_SNAKE_CASE.
Module-level globals (like loggers or constants): Prefix with an underscore _.
Docstrings
We adhere to the NumPy docstring style guide. Every function, class, and module should have a docstring that adheres to this style. This helps in generating consistent and readable documentation. Ensure:
Every module, class, and function/method has an accompanying docstring.
Always describe parameters, return types, and raised exceptions.
Include examples in function/method docstrings when possible.
Testing
Ensure that your code does not introduce new bugs:
Write unit tests for your new features.
Run all the tests to make sure they pass.
Follow the existing testing conventions in the codebase.
Commit Guidelines
Commit messages should be concise and descriptive.
Use the present tense (“Add feature” not “Added feature”).
Use the imperative mood (“Move cursor to…” not “Moves cursor to…”).
Limit the first line to 72 characters or less.
Reference issues and pull requests liberally after the first line.
Final Thoughts
Before submitting your code, review these guidelines and check your code against them. Taking the time to ensure your code adheres to these standards will make the review process smoother and faster.
Thank you for your contribution and for making POSYDON’s codebase clean and consistent!