Skip to content

Commit 3ba114b

Browse files
DEV: add GitHub Copilot instructions for codebase consistency and development practices
1 parent 71e2b3a commit 3ba114b

File tree

1 file changed

+238
-0
lines changed

1 file changed

+238
-0
lines changed

.github/copilot-instructions.md

Lines changed: 238 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,238 @@
1+
# GitHub Copilot Instructions for RocketPy
2+
3+
This file provides instructions for GitHub Copilot when working on the RocketPy codebase.
4+
These guidelines help ensure consistency with the project's coding standards and development practices.
5+
6+
## Project Overview
7+
8+
RocketPy is a Python library for 6-DOF rocket trajectory simulation.
9+
It's designed for high-power rocketry applications with focus on accuracy, performance, and ease of use.
10+
11+
## Coding Standards
12+
13+
### Naming Conventions
14+
- **Use `snake_case` for all new code** - variables, functions, methods, and modules
15+
- **Use descriptive names** - prefer `angle_of_attack` over `a` or `alpha`
16+
- **Class names use PascalCase** - e.g., `SolidMotor`, `Environment`, `Flight`
17+
- **Constants use UPPER_SNAKE_CASE** - e.g., `DEFAULT_GRAVITY`, `EARTH_RADIUS`
18+
19+
### Code Style
20+
- Follow **PEP 8** guidelines
21+
- Use **Black formatter** for code formatting
22+
- Line length: **88 characters** (Black's default)
23+
- Use **type hints** for function parameters and return values
24+
- Organize imports with **isort**
25+
26+
### Documentation
27+
- **All public classes, methods, and functions must have docstrings**
28+
- Use **NumPy style docstrings**
29+
- Include **Parameters**, **Returns**, and **Examples** sections
30+
- Document **units** for physical quantities (e.g., "in meters", "in radians")
31+
32+
### Testing
33+
- Write **unit tests** for all new features using pytest
34+
- Follow **AAA pattern** (Arrange, Act, Assert)
35+
- Use descriptive test names following: `test_methodname_expectedbehaviour`
36+
- Include test docstrings explaining expected behavior
37+
- Use **parameterization** for testing multiple scenarios
38+
39+
## Domain-Specific Guidelines
40+
41+
### Physical Units and Conventions
42+
- **SI units by default** - meters, kilograms, seconds, radians
43+
- **Document coordinate systems** clearly (e.g., "tail_to_nose", "nozzle_to_combustion_chamber")
44+
- **Position parameters** are critical - always document reference points
45+
- Use **descriptive variable names** for physical quantities
46+
47+
### Rocket Components
48+
- **Motors**: SolidMotor, HybridMotor, LiquidMotor classes
49+
- **Aerodynamic Surfaces**: They have Drag curves and lift coefficients
50+
- **Parachutes**: Trigger functions, deployment conditions
51+
- **Environment**: Atmospheric models, weather data, wind profiles
52+
53+
### Mathematical Operations
54+
- Use **numpy arrays** for vectorized operations
55+
- Prefer **scipy functions** for numerical integration and optimization
56+
- **Handle edge cases** in calculations (division by zero, sqrt of negative numbers)
57+
- **Validate input ranges** for physical parameters
58+
- Monte Carlo simulations: sample from `numpy.random` for random number generation and creates several iterations to assess uncertainty in simulations.
59+
60+
## File Structure and Organization
61+
62+
### Source Code Organization
63+
64+
Reminds that `rocketpy` is a Python package served as a library, and its source code is organized into several modules to facilitate maintainability and clarity. The following structure is recommended:
65+
66+
```
67+
rocketpy/
68+
├── core/ # Core simulation classes
69+
├── motors/ # Motor implementations
70+
├── environment/ # Atmospheric and environmental models
71+
├── plots/ # Plotting and visualization
72+
├── tools/ # Utility functions
73+
└── mathutils/ # Mathematical utilities
74+
```
75+
76+
Please refer to popular Python packages like `scipy`, `numpy`, and `matplotlib` for inspiration on module organization.
77+
78+
### Test Organization
79+
```
80+
tests/
81+
├── unit/ # Unit tests
82+
├── integration/ # Integration tests
83+
├── acceptance/ # Acceptance tests
84+
└── fixtures/ # Test fixtures organized by component
85+
```
86+
87+
### Documentation Structure
88+
```
89+
docs/
90+
├── user/ # User guides and tutorials
91+
├── development/ # Development documentation
92+
├── reference/ # API reference
93+
├── examples/ # Flight examples and notebooks
94+
└── technical/ # Technical documentation
95+
```
96+
97+
## Common Patterns and Practices
98+
99+
### Error Handling
100+
- Use **descriptive error messages** with context
101+
- **Validate inputs** at class initialization and method entry
102+
- Raise **appropriate exception types** (ValueError, TypeError, etc.)
103+
- Include **suggestions for fixes** in error messages
104+
105+
### Performance Considerations
106+
- Use **vectorized operations** where possible
107+
- **Cache expensive computations** when appropriate
108+
- Consider **memory usage** for large datasets
109+
- **Profile critical paths** in simulation code
110+
- Keep in mind that RocketPy must be fast!
111+
112+
### Backward Compatibility
113+
- **Avoid breaking changes** in public APIs
114+
- Use **deprecation warnings** before removing features
115+
- **Document API changes** in docstrings and CHANGELOG
116+
117+
## AI Assistant Guidelines
118+
119+
### Code Generation
120+
- **Always include docstrings** for new functions and classes
121+
- **Add type hints** to function signatures
122+
- **Include input validation** for public methods
123+
- **Follow existing patterns** in the codebase
124+
- **Consider edge cases** and error conditions
125+
126+
### Code Review and Suggestions
127+
- **Check for consistency** with existing code style
128+
- **Verify physical units** and coordinate systems
129+
- **Ensure proper error handling** and input validation
130+
- **Suggest performance improvements** when applicable
131+
- **Recommend additional tests** for new functionality
132+
133+
### Documentation Assistance
134+
- **Use NumPy docstring format** consistently
135+
- **Include practical examples** in docstrings
136+
- **Document physical meanings** of parameters
137+
- **Cross-reference related functions** and classes
138+
139+
## Testing Guidelines
140+
141+
### Unit Tests
142+
- **Test individual methods** in isolation
143+
- **Use fixtures** from the appropriate test fixture modules
144+
- **Mock external dependencies** when necessary
145+
- **Test both happy path and error conditions**
146+
147+
### Integration Tests
148+
- **Test interactions** between components
149+
- **Use real data files** for atmospheric models and motor thrust curves
150+
- **Verify end-to-end workflows** (Environment → Motor → Rocket → Flight)
151+
152+
### Test Data
153+
- **Use realistic parameters** for rocket simulations
154+
- **Include edge cases** (very small/large rockets, extreme conditions)
155+
- **Test with different coordinate systems** and orientations
156+
157+
## Project-Specific Considerations
158+
159+
### Simulation Accuracy
160+
- **Maintain numerical precision** in calculations
161+
- **Use appropriate integration methods** for different scenarios
162+
- **Validate against known analytical solutions** when possible
163+
- **Test with real flight data** for validation
164+
165+
### User Experience
166+
- **Provide helpful error messages** with context and suggestions
167+
- **Include examples** in docstrings and documentation
168+
- **Support common use cases** with reasonable defaults
169+
- **Make complex features accessible** through simple APIs
170+
171+
### Community and Collaboration
172+
- **Follow the development workflow** described in the docs
173+
- **Use descriptive commit messages** with appropriate prefixes (ENH:, BUG:, DOC:, etc.)
174+
- **Reference issues** in commits and pull requests
175+
- **Be inclusive and welcoming** in code comments and documentation
176+
177+
## Examples of Good Practices
178+
179+
### Function Definition
180+
```python
181+
def calculate_drag_force(
182+
velocity: float,
183+
air_density: float,
184+
drag_coefficient: float,
185+
reference_area: float
186+
) -> float:
187+
"""Calculate drag force using the standard drag equation.
188+
189+
Parameters
190+
----------
191+
velocity : float
192+
Velocity magnitude in m/s.
193+
air_density : float
194+
Air density in kg/m³.
195+
drag_coefficient : float
196+
Dimensionless drag coefficient.
197+
reference_area : float
198+
Reference area in m².
199+
200+
Returns
201+
-------
202+
float
203+
Drag force in N.
204+
205+
Examples
206+
--------
207+
>>> drag_force = calculate_drag_force(100, 1.225, 0.5, 0.01)
208+
>>> print(f"Drag force: {drag_force:.2f} N")
209+
"""
210+
if velocity < 0:
211+
raise ValueError("Velocity must be non-negative")
212+
if air_density <= 0:
213+
raise ValueError("Air density must be positive")
214+
if reference_area <= 0:
215+
raise ValueError("Reference area must be positive")
216+
217+
return 0.5 * air_density * velocity**2 * drag_coefficient * reference_area
218+
```
219+
220+
### Test Example
221+
```python
222+
def test_calculate_drag_force_returns_correct_value():
223+
"""Test drag force calculation with known inputs."""
224+
# Arrange
225+
velocity = 100.0 # m/s
226+
air_density = 1.225 # kg/m³
227+
drag_coefficient = 0.5
228+
reference_area = 0.01 #
229+
expected_force = 30.625 # N
230+
231+
# Act
232+
result = calculate_drag_force(velocity, air_density, drag_coefficient, reference_area)
233+
234+
# Assert
235+
assert abs(result - expected_force) < 1e-6
236+
```
237+
238+
Remember: RocketPy prioritizes accuracy, performance, and usability. Always consider the physical meaning of calculations and provide clear, well-documented interfaces for users.

0 commit comments

Comments
 (0)