Update Naming Guidelines authored by Brennan Mulligan's avatar Brennan Mulligan
%Naming Guidelines%
Great styling and naming schemes for classes, variables, objects, and methods is extremely important. It allows better readability not just for yourself and your team but for future teams working on this.
**Consistency** is key. When the same thing is used in multiple places such as variables, methods, objects, use the same name. This helps readability between classes as you are clearly talking about a specific thing that is used there and nowhere else.
#Consistency is Key#
When the same thing is used in multiple places such as variables, methods, objects, use the same name. This helps readability between classes as you are clearly talking about a specific thing that is used there and nowhere else.
#Variable Guidelines#
**Variables** must follow camelCase (including IDs). Examples: freshmenFunTimes, teacherId.
Variables should **match** what they are in the database and in other classes if its the exact same thing.
If **multiple similar variables** use similar names, maintain a consistent style. For example, do not create playerHat and shirtPlayer, stick to the same style like playerHat and playerShirt.
#Method Guidelines#
This also goes for **methods** and **classes**. Multiple similar objects, like DTOs, should have the consistently styled names, like PlayerDTO and QuestDTO.
Keep **method names** brief, but descriptive. They should be easy to use, specific to what it is doing, and easy to quickly understand by those who use it.
Always use "get" in methods, not "receive". For example, use getObject, not receiveObject.
#Class Guidelines#
**Singleton** classes will have a singleton variable, not an instance. (This means that the method for getting the singleton is getSingleton, not getInstance.)
**Name classes** off of what they specifically do, not off of a single method inside of it.
......
......