Coding C# in Style

I admit it; I’ve got problems. I get itchy when my code isn’t arranged in the right order, I get the shakes when I open a file and see code sprawling all over the place, I get nervous when my fields aren’t prefixed with an underscore. So I work to my own personal style, strictly adhering to some key guidelines.

Private Fields Are Underscored

This helps me tell at a glance whether the variable I’m assigning to is class-level or method level. It provides a little bit of context and a reminder of where a variable belongs in a class – is a throwaway variable or could other methods be working with it?

Tabs, Not Spaces

This is probably the subject of a thousand flame-wars on forums and mailing lists across the internet, but I opt for tabs. I also work with Visual Studio’s “View White Space” option switched on so I can check for excess tabs and line breaks more easily. I told you I had a problem.

Regions Are Your Friend

When I open a class file, I’ve usually got a purpose in mind, and seeing reams of code is a surefire way to make me dismay. On the other hand, opening a file which is organised using regions means I can quickly focus on the area I want to act upon. It also allows me to collapse the code I’ve been investigating back to an “overview” state using Visual Studio’s CTRL+M, CTRL+O shortcut.

Save Me, Resharper

As with most Visual Studio operations, Resharper is there to help. In this case, JetBrains provided a great new feature for R#3 – the Type Members Layout options. By supplying an XML layout, you can tell R# to reorganise your code into a specific order within specific regions. I’ve uploaded my current Layout XML, which will reorganise your code in my style – fields, properties, constructors then methods – all within their own region. If only JetBrains could come up with something to enforce naming conventions and other coding styles!


I’ve heard people a number of times that it’s better to enforce any coding style, even if your team doesn’t agree with some aspects, than to not enforce anything at all. I totally agree with this statement – from C# to Javascript to CSS and SQL, if you make sure your developers work to a single standard you can be sure they can jump into a file and not be terrified. Ok, not be really terrified anyway. Let me know about the guidelines your company enforces and which tools, if any, you use to do so!

This entry was posted in c#, resharper, style guidelines. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

10 Responses to Coding C# in Style

  1. Cheers to that Colin!

    I know what you mean about being very peticular about how the code is arranged in the files.

    A couple of things I follow in my own coding styles are:
    - Underscores like you mentioned for class level private variables
    - Camel casing on private fields, Pascal casing on public fields
    - Private fields go at the top, followed by ctors, then properties and finally methods
    - All brackets are on their own line
    - using statements at the very top of the file outside the classes namespace decleration

    thats all I can think of off the top of my head.

    good post! I think it aspires to each of us

  2. The only thing I can add guys is that my contacts are all capped and separated by underscores (i.e., MY_CONST_NUMBER)

    ReSharper is your friend.

    I personally don’t like regions, if you have to use them, your class is probably doing too much. To avoid a backlash though, it depends (aha…my Ocampo moment) on what the team decides on.

    I could code with my variables going backwards, just as long as their are standards agreed upon by the team.

    Excellent first post Colin.

  3. Wow. Drifting at 10pm. I need sleep. I meant constants not contacts.

  4. Joe Ocampo says:

    I have a concern with this statement,

    “…and seeing reams of code is a surefire way to make me dismay.”

    Jason eluded that regions tend to hide technical dept. This is occurring because of low cohesion and solubility. This is a code smell.

    Look for orthogonal constructs within the object where behavior can be refactored into other objects. The will lead to a more supple design.

    my two cents. OK maybe a nickel. :-)

  5. cramsay says:

    I know what you’re saying Joe, and I kind of agree. But regions don’t make code bad, it’s just that too many could be a reflection that you’ve got issues somewhere. I tend to just have them there to group my main constructs – fields, methods, etc – together, and no more. On rare occasions I’ve found myself thinking of using nested regions and it’s then I know I’m in trouble.

  6. Joe says:

    Thanks for the tip on the XML layout — I wasn’t aware you could do that,.

  7. joeyDotNet says:

    I would agree that too many regions generally point to a smell. I used to be emphatic about regionizing all of my code. But now I just let ReSharper 3 (defaults) do everything for me. Less I have to worry about.

    Oh, and I dropped the “_”‘s from my private variables over a year ago. With tools like R# that can color code your private variables different from method parameters and local variables, I don’t really see the need in using the extra noise of underscores. But of course, like most things, it’s all about personal/team preference.

    Bottom line, before I had ReSharper I was absolutely obsessed with keeping my code perfectly organized, but now it “just happens” for me, leaving me to worry about more important things.

    Thank you JetBrains!!!

    (I’ll up the ante and say that’s my .10) ;)

  8. Ed says:

    We follow the Juval Lowy standard, with the exception of not prefixing our fields with the Hungarian notification m_ (just _ )

  9. James Nies says:

    Great post Colin! I too am very particular about code arrangement and style.

    Several years ago I had gone so far as to write a VS macro to help my team and I keep a large C# codebase “clean” (members grouped in regions, sorted, etc.). For something that had just been thrown together in my spare time, it seemed to have a very positive impact on our productivity. However, after moving on to a different project, I soon realized that my macro would need a lot of work to match the style conventions of any other team.

    Thus, I set out to create a tool that was configurable and didn’t rely on the Visual Studio FileCodeModel. I’ve never used ReSharper or it’s Type Members Layout feature, but believe my tool is very similar in concept (i.e. uses an XML configuration to define the code layout).

    NArrange is open source and you can check it out at:

    Looking forward to any feedback…