mirror of
https://github.com/OPM/ResInsight.git
synced 2026-10-27 23:50:19 -05:00
* Adopts dynamic PDM buttons with lambda callbacks Refactors PDM push buttons from boolean fields to use the `addNewButton` API with direct lambda callbacks. This change enforces a new coding guideline to extract complex or multi-line lambdas to dedicated `on*Clicked()` methods, improving code readability and maintainability. - Replaces `PdmField` button fields with `PdmUiOrdering::addNewButton` calls. - Extracts multi-line/control-flow lambdas into named methods in `RimFlowCharacteristicsPlot`, `RimGeoMechCase`, and `RimStatisticsContourMap`. - Removes obsolete `defineEditorAttribute` overrides and `fieldChangedByUi` logic for these buttons. - Updates `RimWellPathFracture` to utilize base class-provided button creation. - Adds new lambda line-count guideline to the coding style documentation. - Includes minor build fixes, such as adding `cafPdmUiButton.h` and correcting tooltip API usage.
2.6 KiB
2.6 KiB
Coding Style Guidelines
This document describes the coding style and formatting conventions for ResInsight.
Code Formatting
clang-format
ResInsight uses clang-format for C++ code formatting:
- Configuration:
.clang-formatfile in repository root - Version: Use clang-format-19 to enforce style
Python Formatting
Python code should be formatted using ruff:
# Format source code
python -m ruff format test_polygons.py
# Check code style
python -m ruff check --fix test_polygons.py
Language Standards
- C++: C++23 standard
- Python: Python 3.8+
Best Practices
General Guidelines
- Minimal Changes: Make the smallest possible changes to achieve the goal
- Preserve Formatting: Do not reformat unrelated code
- Comments: Match the style of existing comments in the file
- Libraries: Use existing libraries whenever possible; only add new libraries or update versions if absolutely necessary
Code Quality
- Always validate changes don't break existing behavior
- Always validate changes don't introduce security vulnerabilities
- Fix any vulnerabilities related to your changes
- Run linters, builds and tests before making code changes to understand any existing issues
- Always try to lint, build and test code changes as soon as possible after making them
Testing
- Only run linters, builds and tests that already exist
- Do not add new linting, building or testing tools unless necessary to fix the issue
- It is unacceptable to remove or edit unrelated tests
- Documentation changes do not need to be linted, built or tested unless there are specific tests for documentation
Lambda Functions
Keep lambdas short and readable:
- 1–3 lines: keep inline
- 4+ lines or contains control flow (if/for/while): extract to a named method (e.g.
onApplyClicked()) and call it from a single-line lambda
// Good – short inline lambda
addNewButton( "Show Report", [this]() { showReport(); } );
// Good – multi-statement, no control flow, still inline
addNewButton( "Clear Data",
[this]()
{
clearData();
updateConnectedEditors();
} );
// Good – complex logic extracted to a named method
addNewButton( "Apply", [this]() { onApplyClicked(); } );
void MyClass::onApplyClicked() { /* complex logic here */ }
Commit Conventions
When creating commits:
- Use issue number at the start of the title:
#12773 Python: Add API for creating valve templates - Follow git conventions for commit messages
- Always run python formatting/check on changed files before commits