Maintaining a code base for six years is a hard task when you don't start early on to create conventions and paradigms for your coding guidelines, especially if you have fluctuations in your programmers (working students, retirements, freelancers,...). Over the years, about 12 different programmers of various experience contributed to our code base. While doing code reviews with colleagues is a good opportunity to teach other (junior) programmers your coding guidelines, it is also important to listen to your coworkers. In fact in my 10 years of coding I've never experienced a single guideline which wasn't broken at least once, but always with good reason. And you should know the reasons and maybe even adjust your guidelines then.
Coding style
The main reason for our guidelines is to create readable and easy to debug code, i.e. no too complex instructions or equations and trying not to hide variables in instructions which could be important for debugging. This of course didn't produce always the best or most optimized code, but that was most times better than having someone not understanding how to fix a bug or even introduce a new one.
A thing which irritated me many times when I got applications for an open programmer position was finding code in a non-english language. One thing was that it was sometimes nearly impossible to read some of the code (no, I can't read chinese, russian,... variable names). The other thing we stumbled upon in our team was that it was merely confusing if people talked about the same thing, but named it differently in their own language (our company is located in Germany). So english were forced to be used in code, comments and (technical) documentation all the time to avoid that confusion.
I've split the guidelines into three categories:
General, general guidelines to consider before actually writing code.
C# specific, which were the guidelines to write any C# code.
Unity specific, which were to avoid some pitfalls in writing for Unity3D.
Again, all the guidelines were not set into stone! If there was a good reason to break one, all had to know why and it was okay for everyone. The most important thing was that all programmers were fine with the guidelines and that they worked for the whole team.
So let's take a look at the guidelines:
General
The coding language is english. Class, variable, function and method names are all in english, as well as all written comments or header information.
Use spaces instead of tabs (that way the code looks the same on every other machine). A tab is 4 spaces.
Names of variables and functions should be descriptive. Long names are no problem, undescriptive names are. Only use abbreviations if they are very clear and commonly known.
No hungarian notation.
Every comma follows a space (e.g. myFunction(int a, int b, int c)).
Use comma to improve readability, but keep it to one comma (e.g. add(1 + 2) instead of add(1+2)).
Avoid making large classes. Extract generic functionality to helper classes. A single class file should not exceed more than 500 lines.
Write short functions, preferably no longer that 100 lines.
Don't write lines that are longer than what fits on a normal 1920*1080 screen.
Produce DRY code. (https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
Keep a loose coupling of classes. (https://en.wikipedia.org/wiki/Law_of_Demeter)
Write functions as functional as possible. (http://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php). Writing functional will make it also easier to separate logic and keep classes smaller.
Use code comments only if needed (e.g. when breaking one of the coding convention rules). Code should speak for itself and commenting it mostly means, that it is written too difficult to understand.
When adding comments for later work, write "TODO:" and end it with your initials in brackets (e.g. "TODO: clean up later (PH)")
Don't disable error and warning messages.
When working with callback delegates, try to include both a successful and failed outcome.
Avoid "magic numbers" (https://en.wikipedia.org/wiki/Magic_number_(programming)#Unnamed_numerical_constants). If constant values are needed, they have to be declared at top of a class.
When working on own branches, update your branch frequently from the master/developer branch to stay up to date and avoid large merge conflicts.
Commit small chunks of changes instead of huge commits. Makes it easier to review and revert.
C# specific
Every class, interface, struct, enum is implemented in its own file. Only class intern private structs, classes, enums are allowed inside the same file (use within reasons).
Actions and events are declared below, after properties and fields.
