Freigeben über

Coding Styles

  • Artikel

From time to time, people ask me about coding styles; if they have seen some of my code, many are curious about my use of post-fixed underscores in private member names. Is this a new Microsoft standard?

No. It is my own, private coding convention. Microsoft has an official naming guideline for .NET at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp, but it only addresses the public API of your code. Visual Studio 2005 Team System's Code Analysis feature and FxCop (https://www.gotdotnet.com/team/fxcop/) help enforce this naming convention, but since it only deals with your public API, you (and I) are free to use whatever naming convention for privates.

Coding style is a very touchy subject for most people, so let me explicitly state that the following is just a summary of my personal coding conventions, and do no not in any way constitute a recommendation by Microsoft (they do, however, carry my personal recommendation). If you have another coding convention that you are happy about, you should stick with that, as long as you conform to our official naming guidelines.

Consider the following class:

 public class MyClass

{

    private string text_;

    private readonly static int number_ = 7;

 

    public MyClass(string text)

    {

        this.text_ = text;

    }

 

    public string Text

    {

        get { return this.text_; }

    }

 

    public static int Number

    {

        get { return MyClass.number_; }

    }

}

Private members are post-fixed with an underscore, and this sometimes puzzles people, as most developers tend to use an underscore as a prefix. The reason I'm not using a prefix is because using a post-fix saves me some typing. When I want to use the text_ member, I can just type this.t, and Intellisense will take care of the rest. Had I prefixed with an underscore, I would have had to type this._t before Intellisense would have enough information to uniquely identify the correct member. And so what? It's only a single, extra character. True, but I find the underscore to break my typing flow, since I have to move my hands ever so slightly to type this character (on my Danish keyboard).

Some people like prefixing because Intellisense will then group all member variables together. This is, however, not a goal for me, since I always use the this keyword, and that helps Intellisense narrowing down my selection options to the (public and private) members of the class.

If I always use the this keyword, then why do I need the underscore at all? Mostly to avoid ambiguity between members and parameter values. Consider MyClass' constructor which takes the text parameter. The naming guidelines dictate that parameters should be correctly named, so my options of naming the parameter are restricted, and I don't want my member variable to have the same name, even if the code would compile, as it wouldn't be very readable.

The post-fixed underscore, then, is just my own convention for disambiguating member variables from parameters, while still retaining a sensible name.

My coding style is also much influenced by the ambition of writing code that is easily readable even outside of Visual Studio. For instance, if you are reading my blog through an aggregator, chances are that all the coloring has been stripped from the code samples, but my code is still readable. It is very easy to determine the scope of a variable just by looking at it:

  • If it stands alone, it's a local variable
  • If it is prefixed by the this keyword, it's an instance class member
  • If it is prefixed by the name of the class (as is the case with the number_ variable in the example), it's a static class member.

As you can see, I have a rationalization for most of my coding style. You may have another rationalization for your style, and as long as you follow the naming guidelines for the public API you should feel free to do what works best for you. My coding style works well for me.

Comments