I follow this style guide to ensure that all Meson build scripts I write are readable, maintainable, and consistent across the Fossil Logic ecosystem. Proper script style improves clarity, reduces errors, and makes it easier for contributors to understand and extend builds.

1. General Principles

• I write clear, concise, and descriptive statements in the build scripts.
• I avoid overly complex one-liners; readability takes precedence over brevity.
• I use consistent indentation and spacing to make the scripts easy to read.

2. Naming Conventions

• I use lowercase_with_underscores for variable names.
• I give targets meaningful names reflecting their purpose, e.g., fossil_sdk_lib, fossil_tests_exe.
• I maintain consistent naming for dependencies, subprojects, and options.

3. Dependency Management

• I explicitly declare dependencies using dependency() and avoid hidden or implicit assumptions.
• I prefer required: true unless optional dependencies are explicitly needed.
• I consistently use subproject() for internal dependencies and clearly separate them from system dependencies.

4. Target Definitions

• I clearly separate library, executable, and test targets.
• I avoid duplicating source lists; instead, I use variables like sources = [...].
• I document target-specific options with comments, e.g., purpose, special flags, or platform notes.

5. Compiler and Linker Flags

• I define flags explicitly using add_project_arguments() or add_project_link_arguments() instead of embedding them in targets directly.
• I use variables for repeated flags to reduce duplication and simplify maintenance.

6. Options and Configuration

• I define options for configurable features using option() with descriptive names and default values.
• I document each option’s effect with comments.
• I ensure feature toggles are consistent across all related targets.

7. Tests and Verification

• I use test() consistently to define unit or integration tests.
• I give tests descriptive names that reflect what they verify.
• I maintain minimal but meaningful test arguments and environments in the script.

8. Comments and Documentation

• I write comments to explain why something is done, not just what.
• I place section headers in larger scripts to separate configuration, targets, and tests.
• I keep comments concise, aligned, and consistent in style.

9. Maintainability and Readability

• I avoid hardcoding paths or repeated strings; I use variables wherever possible.
• I group related statements together for logical flow.
• I aim for scripts that are easy to read top-to-bottom without needing external context.

10. Version Control Considerations

• I ensure that the Meson build script works in a clean checkout with no hidden dependencies.
• I avoid local environment assumptions; scripts should build consistently across machines.