Appendix N: Coding Conventions and Style Guide - ApertureViewer/Aperture-Opertations-Manual GitHub Wiki

Coding Conventions

  • Aperture Commenting Style (Mandatory for all Aperture-specific code):
    • Use // <AP:TAG> ... // </AP:TAG> block comment tags for all multi-line code changes specific to Aperture. TAG should be the contributor's unique initials or GitHub username (e.g., <AP:JD> for John Doe). The Project Lead, William Weaver, uses <AP:WW>.
    • For single-line Aperture-specific changes: // <AP:TAG/> My change explanation. (Contributor uses their own TAG).
    • When modifying existing Firestorm/Linden Lab code, preserve the original code by commenting it out within // <FS:TAG> ... // </FS:TAG> blocks if it's being replaced or significantly altered. (Contributor uses their own TAG for the <FS:TAG> block).
    • Place Aperture comments logically. If modifying code within an existing Firestorm developer's block (e.g., <FS:Ansariel>), Aperture comments should be nested within that block if the change is related, or clearly outside if it's a separate concern.
    • Rationale: Clear attribution and differentiation of Aperture code from upstream code is critical for maintainability, understanding, and potential future merges or PRs.
  • File Type Specific Commenting (General Comments):
    • .cpp, .h, CMakeLists.txt, .rc, .nsi, .py, .sh:
      • Use // for general C++/CMake style comments.
      • Use # for general Python comments.
      • Use # for general shell script (.sh) comments.
      • Use ; or # for general .nsi (NSIS installer script) comments.
      • Use // for .rc (Windows Resource file) general comments.
    • Consistency within Firestorm conventions: For <FS:TAG> blocks, Firestorm sometimes uses // even in .nsi or .sh. For Aperture blocks <AP:TAG>, strive for native comment styles where appropriate but prioritize clarity.
  • Code Style:
    • Indentation: Use spaces, not tabs. This aligns with Linden Lab and Firestorm coding conventions. Configure your editor accordingly (typically 4 spaces per indent level, but match existing code).
    • Generally follow existing style in the Firestorm codebase (indentation, spacing, naming conventions) for consistency, unless a specific Aperture style guide is developed.
    • When in doubt, prioritize clarity and readability.
⚠️ **GitHub.com Fallback** ⚠️