smack-a-brother/CLAUDE.md

• C++, with Cmake.
• Third party libraries should be included as git submodules and built statically with the program; never dynamic.
• For something like SDL, make sure that only the build options only include stuff the program needs.
• Use snake_case for functions.
• Use SCREAMING_SNAKE_CASE for constants/constexprs.
• Use camelCase for variables
• Use snake_case for file names and folders.
• Variables should be declared on separate lines, even if they're the same type.
• Don't use magic numbers, except for the very common stuff like -1, 0, 1, 2. Constants should have a symbol attached to them.
• Use newlines to sort code "logically", into blocks, to be more readable.
• Newlines for { and }, except if the clause contained inside is one line, then exclude them.
• Booleans (both functions returning them and variables) should always be prepended with "is", even if it grammatically wouldn't make sense.
• Avoid use of anonymous namespaces. For namespaces, try to have them match files; don't create superfluous namespaces within documents.
• Case statements inside switches should be indented.
• Comments and other in-code writings should abstain from using semicolons to separate clauses. Prefer newlines and simple sentences.
• Prefer "manager" classes with a suite of functions as methods rather than ones operating on structs, for units that necessitate them.
• Sort struct members/variable declarations logically; try to clump same-typed variables together, in alphabetical order.
• Little to no comments; one at the top of structs/functions to explain broad behavior concisely. Code should be self-explaining.
• Keep function parameters low; prefer passing larger references rather than a number of parameters.
• Functions should use snake case and should typically be written like "[noun]_[verb]". Try and use a limited amount of verbs to describe functionality; "save", "load", etc.
• Avoid use of "const" unless needed (not constexprs); it really doesn't matter tbh.

If user asks for "how to", or "why", that's an indicator to generate no code and simply answer their prompt.

Always strive to cut down code whenever possible, and to reduce complexity, reuse functions and behaviors, etc. Identify places where line/file count can be trimmed.

Performance, low compile time, and quick initialization of the program are high priorities.

Relentlessly pause execution to ask the user questions about project architecture, and to guide them and help assist them understand the software being produced.