VS Team Coding Conventions

These are the coding guidelines the VS Team tries to adhere to

DRY - Don't repeat yourself

Code duplication is evil and should avoided where possible, unless it it significantly violates other guidelines, such as code readibility.

SoC - Separation of concerns

Thematically different code/configuration should be placed in different code structures. The game engine should not be concerned with game content - so they are, where practically possible, separated into their own mods. The code that defines the behavior of blocks should not be concerned with the configuration of that block, so the configuration is, where practically possible and meaningful, separated into json files. Animations, UVs, Models, Textures - none of them should be defined inside source code where practically possible.

Subdivide complexity

Complex code should be organized in order of specificity - from broad to specific. The mod API is designed this way. It starts with a very broadly defined class - ICoreAPI, which subclasses into ever more specific functionality.

Write readable code

Good code is self-documenting. Fields and Properties should be named by what they contain, and methods should be named by what they do.

Field names

• For tight for loops i,j,k,l are commonly used for the counter.
• Dictionary, and sometimes 2D arrays, are usually named in the form of XXXbyYYY. Where as XXX describes the value in plural form and YYY describes the key, example: Dictionary<string, ClientPlayer> PlayersByUid
• The names of Arrays and Lists should be in plural form
• Boolean values are preferrably prefixed with Is*, Can*, Should*

Method names

Almost all method names begin with a verb, describing what the method does. Some examples:

• Load*() - loads data, but does not return it
• Get*() - reads/returns data
• Set*() - sets data
• GetOrCreate*() - returns data, or if it doesn't exist, initializes new one
• Register*() / Unregister*() - Add/Remove instanced classes or class names to/from a list to be used widely by other systems
• From*()/To*() - code that converts data from one type to another
• Try*() - code that runs control logic or returns data by reference, that might not be successful. Returns a boolean value.
• On*() - code that runs control logic, triggered by an event or a game tick
• Trigger*() - code that triggers an event

Code Comments

Code comments should describe why something is written in a particular way and not what the code is currently doing - as the latter should always be self-evident (if it is not, then it is not readable enough). Exception: Code comments are sometimes useful to divide code into sections