Code Style

Naming

Classes use PascalCase

Everything else uses camelCase

Abbreviations

Do not use abbreviations. Always write out the whole word. If a variable name is too unwieldy, use an acronym instead.

The only exception is for names which are reserved words. These should be avoided in the first place but the following are acceptable abbreviations:

• arr for arrays
• fn for functions
• num for numbers
• obj for objects
• str for strings

Acronyms

Acronyms should always be fully upper-case or fully lower-case. Which one depends on their position within the variable name: if they are the first “word” in the name, they should be fully lower-case, however if they are the 2nd or later “word”, they should be fully upper-case.

.entityIds   // wrong
.entityIDs   // correct

.JSONData    // wrong
.jSONData    // wrong
.jsonData    // correct

Class Structure

Classes should be organized in the following order:

1. Property declarations
2. Constructor
3. get and set functions, grouped by property, alphabetically
4. All other methods, alphabetically

Comments

These rules should be observed when writing comments.

General

Single line comments can be sentence fragments, and should be at most a single sentence with no end-punctuation.

Multi-line comments should be full sentences including punctuation.

Documentation

Avoid “this”.

This is a class, not an instance, so use “the [class],” instead of “this [class]” to refer to whatever entity instance is actually calling the function.

Be concise.

For example, avoid writing “type of component” and instead say simply ”component type.”