Unity 3D & C#

Unity3D is a powerful suite of tools (Project IDE, Code IDE, run-time) for game development.

As always, RivelloMultimediaConsulting.com/unity/ will be the central location for deep articles and tutorials, Facebook.com/RivelloMultimediaConsulting (like us!) will engage the growing RMC+Unity community, and for the latest opinions and cool links follow me at Twitter.com/srivello.

There is incredible momentum in the Unity3D product and its community.

In this post I show the Microsoft coding conventions of C#. These are recommended by, but not required by, Unity Technologies for Unity’s C#. I compare those to my own RMC coding conventions (Rivello Multimedia Consulting).

It should be noted that the implementation of C# in Unity is based on Mono. Mono is a software platform designed to allow developers to easily create cross platform applications. Sponsored by Xamarin, Mono is an open source implementation of Microsoft’s .NET Framework based on the ECMA standards for C# and the Common Language Runtime. As far as I can tell, Unity’s C# is the same as .NET’s C# in its approach to coding conventions.

Naming Conventions

they are blah…

I famously (famous in my little world) published my coding standards years ago. They were based on ECMA-script standards and Hungarian notation. I used it myself and within my teams extensively. My projects were non-C# at the time. Now my projects are C# (Unity), so this post is exclusively related to C#.

Terms

• 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.

Benefits of Adopting A Coding Convention

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?

Controversy

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.

Comparison: C# vs RMC

I created a single example of both 1. RMC naming conventions and 2. C# naming conventions. You can see that snippets 1.1 and 2.1 between the two standards are similar, however all other snippets are different. The code is below (and also attached as CSharpCodingStandardsTemplate.cs). Below the indentation has been removed for easier reading.

void Start ()
{

//—————————————————————–
// 1. RMC Naming Conventions
//
// (See http://www.rivellomultimediaconsulting.com/c-sharp-coding-conventions-and-standards/ )
//
//—————————————————————–

// INSTANTIATE
//1.1
ClassWithRMCConventions classWithRMCConventions = new ClassWithRMCConventions();

// STATIC MEMBER
//1.2
ClassWithRMCConventions.SamplePublicStaticMethod(“foo”);
//1.3
string s1 = ClassWithRMCConventions.SAMPLE_PUBLIC_STATIC_CONSTANT;

// INSTANCE MEMBER
//1.4
classWithRMCConventions.samplePublicMethod(“blah”);
//1.5
classWithRMCConventions.samplePublicVariable = “foo blah”;

//—————————————————————–
// 2. C# Naming Conventions
//
// (See http://msdn.microsoft.com/en-us/library/vstudio/ff926074.aspx)
// (See http://msdn.microsoft.com/en-us/library/ms229045.aspx)
//
//—————————————————————–

// INSTANTIATE
//2.1
ClassWithCSharpConventions classWithCSharpConventions = new ClassWithCSharpConventions();

// STATIC MEMBER
//2.2
ClassWithCSharpConventions.SamplePublicStaticMethod(“foo”);
//2.3
string s2 = ClassWithCSharpConventions.SamplePublicStaticConstant;

// INSTANCE MEMBER
//2.4
classWithCSharpConventions.SamplePublicMethod (“blah”);
//2.5
classWithCSharpConventions.SamplePublicVariable = “foo blah”;

//—————————————————————–
// A. Analysis of Naming Convention – Class External
// (Referring ONLY to outside of a class, its API, as shown above)
//
// 1. RMC Convention is **unique** across each; public vs. static,
// method vs variable, non-constant vs constant.
//
// 2. CSharp Convention is **the same** across each.
//
//—————————————————————–

//—————————————————————–
// B. Analysis of Naming Convention – Class Internal
// (Referring ONLY to inside of a class)
//
// 1. RMC Convention is TBD.
// 2. CSharp Convention is TBD.
//
//—————————————————————–

}

References

• Wikipedia – Programming Naming Conventions
• Unity Technologies – Official Coding Convention Video
• Microsoft .Net – C#Naming Conventions
• MonoProject – Style Conventions

What Do YOU Think?

Have a comment? Please post below. This is a hot topic and I’ll respond promptly over the next month.