Conventions

Vaulted Vulkan uses a strict style convention for C++ that focuses on maximizing comprehensibility of the library implementation without necessarily needing to leave your IDE for the documentation.

The convention focuses on the following:

• Clear and concise naming: Mnemonics are avoided unless the names get outrageously long.
• Liberal use of contextual identifiers: Library was designed to be understandable by just reading the name / scope of objects to get full context of their definition.
• To be used in a modern environment: The implementation is not designed to be read on paper. It expects proper syntax highlighting and is designed to be used with code completion/content assist/code hinting.
• Minimal standard language abstraction: The library attempts not to really wrap the standard library. Any used during development will be removed. (Exceptions are within VV_CPP_STL.hpp, they are also transparent/1:1 to the type wrapped)
• Ideal Visual Alignment of information: If related symbolic information within the implementation can be aligned for ease of legibility it will be.

Naming

Macros: VV_Context_Name_Of_Macro

Enums: ENameOfEnum

Global Constants or Variables: UpperCamel

Struct Members: UpperCamel

Class Members:

• Public: UpperCamel
• Protected: lowerCamel
• Private: lowerCamel

Functions names: (Currently UpperCamel)
(In future update)
public: UpperCamel_Upper_Snake
private: UpperCamel_lower_snake
(Where each starts with a verb and the "snake" is specifier)

Function Parameter names: _lowerCamel

Function stack variable names: lowerCamel

Function static variable names: _UpperCamel
(I need to fix this in a bunch of places, I didn't follow it I believe...)

Function Pointers: FPtr_NameOfFunction

Type Naming: UpperCamel

Pointer Indirection

• All indirections greater than 1 must be at least type wrapped or a struct wrap. (Example: using VoidPtr = void*; PtrVoid* pointerArray; or struct Fields { char* Name; char* Date; }; Fields* fieldsArray; )
• If using const on an indirection of greater than 1, it must also be type wrapped.

Referencing Preferred

If possible, a reference will be used over a pointer indirection. The only case for using pointer indirection is for parameters or members that are intended to hold optional data or arrays of data.

Compile-Time Deduction Preferred over Preprocessor deduction.

If its possible to use constant expressions or templates in place of preprocessor macros they will be used.

Exceptions:

• Defining library use options that would "uglify" the implementation if Macros were not used. (Example: Omitting entire sections of implementation from being defined, this is quite egregious in template implementation as compared to macros)