30 lines
2.5 KiB
Markdown
30 lines
2.5 KiB
Markdown
- 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.
|