Coding Guidelines

Apply these rules to ensure code quality, maintainability, and adherence to project standards.

Fight for Truth

Don't write things that aren't currently true — anywhere. Chat, code comments, variable names, PR titles, READMEs, commit messages.

• Documentation and comments that do not match the code are considered untrue.
• Variable names that do not match the purpose of the variable are considered untrue.
• Temporary workarounds that aren't labelled as such are lying through omission - there is an issue you aren't telling the next programmer about. Mark them with a TODO comment with a link to a git issue (if it exists) and telling the next programmer when they can delete the workaround.
• If unsure of something, say so. Bluffing is lying.
• Ambiguity is a soft lie: if a phrase could be read two ways and only one is true, it's misleading. Disambiguate before sending — pick the term that says exactly what's meant, name the antecedent of every "it"/"this"/"that".
• A wrong statement is worse than no statement.
• Separate scratch labels from real identifiers.

Actively fix untrue things when you see them. Don't let "close enough" wording stand in for the truthful one.

Grep before naming. Before sending any prose, walkthrough, README, comment, or commit message that names a specific identifier (function, struct, file, account, module, field, constant), grep the source for that exact identifier and confirm it exists. "I'm pretty sure that's the name" is not enough. If the identifier doesn't exist, either use the real name or apply the rename to the code first, then write the prose.