Home - Booklordofthedings/Beef-Styleguide

Table of Contents

Beef Styleguide

Naming
Formatting
Code Style

Beef Styleguide

This is a very basic styleguide for naming things and how to code in Beef.
Its formatted as a list of rules to make it somewhat easier to read and understand.

No rule is absolute and there may be legitimate reasons to break them.

Naming

Names are either camelCase or PascalCase
Classes should be named in PascalCase
Structs and enums can be camelCase but dont have to be
This specifically depends on their usage. If it is supposed to be treated similar to a primitive it should be camelCase, otherwise its PascalCase. (This also means that a class that behaves like a primitive could be named in camelCase, but thats unlikely to occur in practice)
Interfaces use the I[Name] syntax
Optionally with the "-able" postfix
Iterators for numerical reasons should use i, j, k, ii
Two of the same character is fine since its visibly different, but further repetition should be avoided
Iterators in foreach type scenarios should use the singular version of the thing they are ( line, entry, key)
Public members, properties and functions should use PascalCase
Private members or functions should use camelCase and prepend a _ infront of them
Local variables use camelCase
Otherwise names should indicate what a variable is used for or what it contains
val/value as a name should be avoided unless used in a generic setting, or in small scopes
Namespaces should use PascalCase
Namespaces should be used instead of prefixes
Prefixes may only be used if the names of objects are very generic or overlap with corlib types
Defines use a screaming case with underscores (A_THING_IS_HERE)

Formatting

Indentation uses tabs
Preprocessor instructions have no indentation infront of them
New Scopes should preferably go onto a newline
Inline functions are one of the few cases where that doesnt need to be the case
Comments that are under 3 lines long can use single line syntax, otherwise multi line comments are appreciated
Avoid putting meaningful content in the opening and closing line of a multi line comment
If a functions has alot of parameters its allowed to seperate them into multiple lines
This depends on line size and as such occurs more frequently for definitions rather than calls. If there are parameters that are short, or logically grouped they can go onto the same line as each other
Inside of a class the members should be at the top, followed by the constructors and then any functions
Functions inside of a class should be ordered so that they are close to related functions

Code Style

Avoid large if trees, instead return early
Always include a default statement for switches over enums
If other code extends that enum, a switch statement would then error