-
-
Notifications
You must be signed in to change notification settings - Fork 67
Capitalize module-level constants and document the convention #248
Description
Problem Statement
The package's module-level constants are inconsistently cased. Some modules already use the conventional UPPER_SNAKE_CASE (_serialization.py has _FORMAT_VERSION and _MOVEMENT_SKIP_SLOTS), but many others use lowercase names: _aerodynamics_functions.py defines _squire, _lamb, _four_pi, and siblings, trim.py defines _seed, and output.py defines a block of roughly forty visualization settings such as _panel_color, _quality, and _bar_title_font_size. docs/CODE_STYLE.md currently says nothing about constants, so there is no documented convention to point to.
Location(s): Most package modules, with the largest clusters in pterasoftware/output.py, pterasoftware/_aerodynamics_functions.py, and pterasoftware/trim.py. The convention itself belongs in docs/CODE_STYLE.md.
Proposed Solution
- Rename the lowercase module-level constants to UPPER_SNAKE_CASE, keeping the leading underscore on private names (for example,
_qualitybecomes_QUALITY). - Leave module-level mutable state lowercase: names like
_logger,_solve_loop_lock, and_indent_levelhold state rather than constants, so the capitalization convention does not apply to them. - Keep constants whose names are written in one of the forms required by
docs/AXES_POINTS_AND_FRAMES.mdordocs/ANGLE_VECTORS_AND_TRANSFORMATIONS.mdin their convention spelling (for example,_free_flight_view_direction_Einoutput.py), mirroring the existing exception for such names in the variable-naming bullet ofdocs/CODE_STYLE.md. - Add a bullet to
docs/CODE_STYLE.mdstating the convention and its two carve-outs, so the practice is documented rather than folklore.