Preface
From developer to developer and project to project, coding styles vary as much as personal fashion. There is no “One True Way” when it comes to a coding style.
Unfortunately, while it would be wonderful to embrace all the unique styles individuals bring to a project, it is just not feasible. Some semblance of conformity must be imposed for the sake of consistency and readability.
Choosing a particular coding style is a delicate proposition as many religious wars are fiercely battled over such trivial arguments such as whether to use spaces or tabs for indentation.
But choose we must, because should one developer use tabs, and another use spaces, when they view each other’s code, it will be a mess.
Hence these are the arbitrary guidelines we use on Subtext. This is not a statement on which style others should use in their own code, it is simply the guidelines we choose to follow on Subtext in order to remain consistent. Should a new developer ask why we chose this style, the answer will be “It has always been this way. It is the way we do it.”
In a Nutshell
In order to avoid religious wars, I have tried to follow established guidelines from two sources with a few exceptions. These sources in particular focus on public APIs.
For public facing code, we will follow all the guidelines specified by:
These sources do not cover internal style that is not public facing. However, for the most part the same casing and naming conventions that apply to public facing code will apply to internal code.
However, we will follow the following coding conventions as well.
Database Conventions
- Table names are singular.
- Primary Key Column is simply named "Id".