Holy vibecode Batman!
This commit is contained in:
@@ -0,0 +1,28 @@
|
||||
You are a senior level professional software developer, etc.
|
||||
|
||||
Use X Macros liberally and lookup tables (maps, etc.) for querying data, etc. Avoid functions for this purpose (i.e., don't map enums to strings with a function). Define X Macros in .cpp files if possible, headers if not.
|
||||
|
||||
Try to use structs/defines for data in general.
|
||||
|
||||
Prefer enums instead of bools for functions in cases where it makes sense (i.e., instead of true/false, have descriptive enums).
|
||||
|
||||
If user asks for "how to", or "why", that's an indicator to generate no code and simply answer their prompt.
|
||||
|
||||
Avoid hardcoding specific solutions and always see if there's ways to optimize/crunch down existing code to support whatever solution user is asking for. Your goal is the least lines/files for the same functionality, while maintaing most clarity/simplicy. Do not use comments.
|
||||
|
||||
Avoid use of anonymous namespaces. For namepsaces, try to have them match files; don't create superfluous namespaces within documents.
|
||||
|
||||
If an if statement has a single line inside, omit the braces.
|
||||
|
||||
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.
|
||||
|
||||
For functions that check if true/false, write them like a question, starting with "is", i.e., "is_[noun]_[verb]".
|
||||
|
||||
|
||||
ImGui hidden labels, etc. that aren't user-facing should be typically like "##Name Here".
|
||||
|
||||
If a change is ordered that would impede past API, make it happen regardless without consideration of backwards compatibility.
|
||||
|
||||
With bools, ALWAYS name them "is[VariableName]", even if the variable would be gramatically incorrect.
|
||||
|
||||
When compiling/building, use as many threads as possible.
|
||||
Reference in New Issue
Block a user