Add Style & Linting

[Lightning11wins]

Add a new, more detailed style guide documenting the new Beeley style in far more detail than the previous document.

TODO

• Configure and run a linter with these new styles.

GitHub Relationships

• Assumes Add centrallix-lib Utilities #130
• Assumes Update Duplicate Detection #77

[greptile-apps]

Greptile Summary

The PR replaces the former Beeley style reference with a substantially expanded, mandatory Centrallix coding-style guide and updates related documentation to point to it.

• Establishes CentrallixCodingStyle.md as the source of truth for new changes.
• Documents conventions for supported languages, error handling, comments, licensing, and formatting.
• Updates contributor instructions and legacy documentation links.

Confidence Score: 5/5

The documentation-only PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
AGENTS.md	Directs contributors to the new authoritative style guide and clarifies copyright-update expectations.
centrallix-sysdoc/CentrallixCodingStyle.md	Adds the comprehensive project coding-style guide covering formatting, language conventions, error handling, documentation, and copyright notices.
centrallix-sysdoc/BeeleyCodingStyle.md	Removes the superseded legacy style guide.
centrallix-sysdoc/CodingStandards.md	Marks the new guide as authoritative and updates style and module-prefix references.
centrallix-sysdoc/Proposals/ClangFormat.md	Updates the formatter proposal to reference the replacement style guide.

_{Reviews (5): Last reviewed commit: "Merge branch 'master' into add-style-lin..." | Re-trigger Greptile}

[Lightning11wins]

The work isn't done, so we can ignore those issues from Greptile for now. They're concerns for later.

[nboard]

This looks really promising overall! I may have gotten a bit too much into the weeds on word choice for this early in the project, but hopefully this is helpful overall.

[nboard]

TODO
I would like to vote for starting lines with the &&/|| operators. I feel it makes it immediately obvious when reading the line that it belongs to the expression above it, and makes it so deleting/adding lines effect fewer lines

[Lightning11wins]

I agree, but I think I remember cases where this caused issues.

[Lightning11wins]

Yeah, I struggled a lot with this code snippet:

const bool font_changed = false
    || style->FontID != context->CurStyle.FontID
    || style->Color != context->CurStyle.Color
    || realComparePrecision(style->FontSize, context->CurStyle.FontSize, PRT_HTMLFM_FONTSIZE_PRECISION) != 0;

I don't really like the false || / true && style I end up using so that we don't have to indent one line differently from every other line.

[Lightning11wins]

I'll make a discussion for this one.

[nboard]

The parts of this document that overlap with B2CodingStandards.md should probably be trimmed out (though, this can wait until the document is in a more final form to ensure you don't accidentally cut content from both documents)

[Lightning11wins]

Added to TODOs, I'll revisit this later. You can mark this as resolved.

[Lightning11wins]

I'll revisit this after Greg's review ensures that the standard won't change significantly in the near future.

[nboard]

Looks great overall! Just a couple of suggestions and continued conversations on 2 of the preexisting discussions.

[Lightning11wins]

The next step is to run a linter with these new rules. However, that merge-conflict all open PRs.