Increasingly, our projects and teams span more programming languages.
The coding standards for C++ presented below are designed specifically for consistency with these existing Coding Standards in C#.
One coding template example is below and the rest are available on GitHub.
Unity3D is a powerful suite of tools (Project IDE, Code IDE, and run-time) for game development. Unity supports several languages, but the community consensus is to use only C#.
Microsoft created C# and published recommended codings standards. I created my own standards with many differences. While Microsofts standards are not created with Unity in mind, mine are.
Regardless of which convention you choose to use for Unity or other platforms, having some sort of convention is considered a good idea by the majority of the development community. A hallmark of Getting Things Done efficiently is to automate what can be automated. Once a team has standards and adopts them (both admittedly time consuming) the time improvements in the daily workflow are notable. There is less discussion on why or how to name things. It just gets done.
Consistency – The code base as a consistency in presentation regardless of team location, spoken language, or individual programmers.
Integration – The code, the review of the code, and your team are more tightly integrated. Theoretically code is more interoperable (copy/paste) and mutually intelligible.
Maintenance – Conventions aid readability. Readability helps new and existing programmers revisit the code base for fixes and improvements.
Communication – Developers more implicitly understand each other in written and verbal communication.
Ownership – More consistency in coding standards across a code-base encourages Collective Ownership, the feeling of respect, care, and reverence developers for their own work and for those who contribute thoughtfully to their own work.
To be fair, there are drawbacks too. The additional time required per team to develop standards, implement standards while coding each day, police such standards is considerable. You may find certain rebellious personalities and certain cultures which value independence may not take to the idea of standardization well. This may limit hiring options and lengthen on-boarding process. What are the other drawbacks?
Few developers argue the benefits of coding conventions, yet many argue if the time and discipline required is worth it. Some developers simply refuse to add ‘cosmetics’ to their code. In their eyes, if it functions well, the code is good enough.
More contentious yet — what are the criteria of a good standards? A few criteria most people can agree on are here.
Consistency – Whatever rules there are should be applied evenly and applied everywhere.
Pragmatism – The convention should be concerned with ‘important’ things and nothing else.
Naming/Coding Conventions – This relates to the how a developer chooses to name and capitalize the custom keywords he uses. Generally each platform/language has a recommended format but NOT a required format. Some IDE’s offer compiler warnings (not errors) which encourage adoption of its recommended format. That is the focus of this post.
Style Conventions – This relates to the how a developer chooses to indent, comment, and add whitespace to his or her programming. Generally each platform/language has a recommended format but NOT a required format. Some IDE’s offer an ‘autoformat’ which will convert your file to its recommended format. That is NOT the focus of this post.
Lower Camel Case – Naming convention where the first letter of a name is not capitalized and each element of the name begins with a capital letter. e.g. iPhoneCase.
Upper Camel Case (aka Pascal Case) – Naming convention where the first letter of a name is capitalized and each element of the name begins with a capital letter. e.g. PowerPoint.