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.
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#
## 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.
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#
## Variable Guidelines
**Variables** must follow camelCase (including IDs). Examples: freshmenFunTimes, teacherId.
**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.
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.
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#
## Method Guidelines
This also goes for **methods** and **classes**. Multiple similar objects, like DTOs, should have the consistently styled names, like PlayerDTO and QuestDTO.
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.
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.
Always use "get" in methods, not "receive". For example, use getObject, not receiveObject.
#Class Guidelines#
## 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.)
**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.
**Name classes** off of what they specifically do, not off of a single method inside of it.
