Code convention - DanielNijkamp/FlippinWorlds GitHub Wiki
To keep development rapid the decision is made to keep the code convention minimal as not to disrupt the speed of development. This is also to make sure development are not foccused on the naming and rather be focussed on the structure of their code. poorly written code with perfect naming would still be poorly written code.
To create the best code possible use these following points alongside common sense and input from fellow teammates. these points will not only make your code more readable but also more maintainable and less coupled.
These points should be used either in small code parts or the development of entire features. they can provide elegant, simple and easily understandable solutions to otherwise complex problems
- DRY(Do Not Repeat Yourself): Keep repittition at a minimum
- SOLID: Use solid principles sparingly where you see it fit to make sure your code is easier to work with.
- Pillars of OOP: abstraction, encapsulation, inheritance, and polymorphism
- Design patterns: These agiant can provide elegant solutions where the issues seen in your context allign with the reasoning of using a certain pattern
- Decoupling: Make sure your code is not super hard-coded and coupled. use common decoupling practices to avoid this.
- Ternary operator: Use this when you need `do this or else` logic with a single condition.
- Think then code: Try to think about how you will structure your code and visualize. then you will only need to code a small amount of time.
Classes should always use PascalCasing
Public variables should always use PascalCasing
Private variables should always use underscore + camelCasing
A class named Player should not have variables with the prefix of player
So:
public class Player
{
private float playerHealth;
}public class Player
{
private float _health;
}local variables should use pascalCase.
Prefer to use the attribute [SerializeField] instead of making a variable public.
If a variable is only read prefer to make the variable { get; private set; }
If a variable is only initialized once and only read prefer to add the readonly keyword
the use of for and foreach does not really matter. whoever it is preffered to use foreach since it is much more readable. if performance becomes an issue use a for loop.
If any iteration is needed to be done in a non-performance critical context consider the use of LINQ statements as these also provide much more readable code at the cost of minimal performance loss.
Code should be compiled without errors and should not hurt the game performance in a significant way. The code should also not be able to crash the application if its not intended to crash.
Abstract classes do not need a base.
Interfaces should be named using the I prefix
Booleans should be named with the is prefixed. so for example:
isPressed, isDead, isFired etc.
methods should always be PascalCase
methods should also be named after their action. if a action only gets and returns a value have it be named Get. if a method should do something make the method name reflect the change that methods should make. Make sure the methods names are not too long and try to seperate logic in seperate methods to compose your logic in a readable way.
Methods also should always have brackets and not be made 1 line