.NET Naming Conventions

I often get asked about the Naming Conventions I adhere to when writing code (C#, naturally).

It made sense to share these in a blog post so I can refer to it in future.

Some of these guidelines (well, one, the underscore on private fields) are negotiable as a matter of style. However, the public stuff is non-negotiable. For this is how .NET APIs should be and failure to adhere to this reflects badly on your code. No, no, no.

I thought a good way to present this would be an example class demonstrating the rules and some comments to help, so here goes:

using System;

// Namespaces are PascalCased
namespace TheJoyOfCode.NamingConventions
{
    // Class names are PascalCased
    public class ExampleClass
    {
        // All public fields, including constants are PascalCased
        public static const string PiAsAString = "3.14";

        // All private fields are camelCased with an underscore [1]
        private readonly string _privateMember;

        // All protected members are PascalCased
        protected int ProtectedField = 12;

        // All internal members are PascalCased
        internal int InternalField = 13;

        // All private methods are PascalCased
        // *** NOTE - All parameters are camelCased
        private double Multiply(double valueA, double valueB)
        {
            // local variables (scoped within a method) are camelCased (no underscore)
            double result = valueA * valueB;
            return result;
        }

        // All private Properties are PascalCased
        // *** NOTE - Acronyms of 2 characters are UPPERCASED (e.g. UI, IO)
        private string UIElementName { get; }

        // All (public and private) properties are PascalCased
        // *** NOTE - Acronyms longer than 2 characters are PascalCased (e.g. Html, Xml)
        public int HtmlLength { get; set; }

        // All public methods are PascalCased
        // *** NOTE - All parameters are camelCased
        // *** NOTE - Abbreviations are not treated as Acronyms (so _Id_entification is Id, not ID).
        private void AlignObjectById(string id, Alignment alignment)
        {
            throw new NotImplementedException();
        }

        // Nested classes are PascalCased, even Private ones
        private class NestedClass : IDisposable
        {
            public void Dispose()
            {
                throw new NotImplementedException();
            }
        }
    }

    // Enums are PascalCased and not plural (unless marked [Flags] in which case the name should be plural)
    public enum Alignment
    {
        // Enum members are PascalCased
        Top,
        Bottom,
        Left,
        Right,
    }
}

// [1] - Note the underscore isn't as recommended by StyleCop but since it applies only to private members, can be considered a matter of style and one that I personally use.

... and as for #region blocks I do not use regions and I don't negotiate with terrorists either.

Tags: C#

Post By Josh Twist

Follow @joshtwist

9:26 AM
08 Sep 2009

» Next Post: MultiBinding for Silverlight 3
« Previous Post: A Suck Less Event Aggregator for Prism?

Comments are closed for this post.

Posted by John @ 09 Sep 2009 12:30 AM
This is a really good resource for .NET Naming Conventions as it gives reasons.

http://www.irritatedvowel.com/Programming/Standards.aspx

Posted by Wes @ 09 Sep 2009 7:54 AM
Nice post, would like to mention that following these conventions can help avoid conflicts between variables in different scopes. This is best demonstrated when initializing members in a constructor, where the arguments are typically camelCase versions of the private members of the class they are initializing and thus the underscore prevents conflict.

Sometimes the rules are pragmatic!

Posted by Magnus J @ 10 Sep 2009 12:46 AM
Great post. These are the .NET naming conventions that I follow myself. And the comment about the #region block is 100% true.

Posted by Noam Gal @ 10 Sep 2009 1:22 AM
very nice post. Straight to the point.
All methods are PascalCased
All properties are PascalCased

no need to separate to public/private.
but it's all good. thanks for making everything clear.

Posted by Matt Hall @ 10 Sep 2009 3:33 AM
Using something like StyleCop for R# would help you maintain a consistency

http://www.codeplex.com/StyleCopForReSharper

Posted by Mike King @ 10 Sep 2009 7:23 AM
Just a thought, but isn't UI an initialism and not an acronym? Just try to pronounce it. If so, shouldn't it be pascal cased? As in UiElementName? Perhaps I'm missing the distinction your making between the two.

I can't really think of an example of a true two letter acronym.

Posted by whatknott @ 10 Sep 2009 7:34 AM
What conventions do you use to name UI controls?

Posted by josh @ 10 Sep 2009 9:39 AM
@Mike King

Hmm - clearly I've more than met my match when it comes to English Language so I'll back out and say - UPPERCASE applies to two character initialisms.

In all seriousness though, this follows the lead set by the BCL team. E.g. UIElement in WPF. System.IO etc...

@whatknott

This has changed over some time but I now tend to go with a PascalCase SubmitButton or CustomerList where the last part of the name states the 'type' of control (note I chose List instead ListBox or ComboBox because it's the idea that i's a list that I think is important). I don't stick to this hard and fast though... What do you use?

Posted by Michael Coles @ 15 Sep 2009 4:25 AM
The only thing I would disagree with here is the camel cased private members with the underscore. The only time an underscore should be used is for a private backing field to a public property with the same name.

Posted by Jamie @ 17 Sep 2009 9:18 PM
Just reading through some of your blog posts and am impressed by their content and usefulness, I will study them in more detail from home. Nice article on naming conventions, slightly different to my own, but I guess each developer has their own unique flavour. I could live with your conventions, except for underscores on fields and no regions ;-)

Posted by josh @ 17 Sep 2009 10:11 PM
Thanks Jamie,

What a nice comment. You're welcome and do come back :)

Welcome

Feeds

Archive

Editors