C# naming and casing conventions

Question

I'm a VB guy that used to prefix module level variables with "_".

I'm using FXCop, StyleCop and (I think the built in Code Analysis, or maybe that is pointing to FXCop, not sure) and I am trying to adopt the most accepted naming conventions. How would you name the following module level private, property and param fields to make all of these code analysis tools happy and conform to commonly accepted or MS standards? Note that having a param name the same as a private module level field can be confusing and FXCop is incorrectly telling me to prefix the "sourcefile" param field reference with "this."

Is my approach to use lower case for module level privates acceptable and all I really need to do is rename the param to something unatural like "mySourceFile" or "sourceFileIn?" It feels forced. params should be Camel cased. Is my module level variable missed cased?

    public class Restartability
    {
        private readonly string sourceFile;

        public Restartability(string sourceFile)
        {
            this.sourceFile = sourceFile;
        }

        public string SourceFile
        {
            get { return sourceFile; }
        }  

   }

This is one of the first StyleCop rules I always switch off. I don't like the verbose `this.` syntax. I too am prefixing my fields with an underscore. — Daniel Hilgarth, Feb 02 '12 at 18:03
Name them however is consistent with your existing codebase first. How you agree to in your organisation second (this involves using prefixes or Hungarian if it helps you read the code). Fall back to the [official guidelines](http://msdn.microsoft.com/en-us/library/ms229012.aspx) third. Last, set up StyleCop to follow *the rules you want*; it just a tool, it doesn't know what's best for you. — millimoose, Feb 02 '12 at 18:07
Remember that a naming convention - every naming convention - is completely arbitrary. Furthermore, in no real codebase will it be the thing that "makes it or breaks it" when it comes to your code being *understandable*. Pursuing standards of readability is worthwhile only up to the point where you don't see the forest for the trees. — millimoose, Feb 02 '12 at 18:16

score 5 · Answer 1 · answered Feb 02 '12 at 18:02

5

I think that private field variables should be prefixed with a '_'.

This would give you:

private readonly string _sourceFile;

However, it can be argued that no prefix should be necessary (from the book Clean Code), since you shouldn't have so many variables in a class that it becomes hard to tell the difference between field scoped varialbes, and non-field ones.

answered Feb 02 '12 at 18:02

Sheldon Warkentin

1,706
2
14
31

1

Warning 1 SA1309: Field names must not start with an underscore. – Chad Feb 02 '12 at 18:05
3

More discussion on that particular warning in another thread: http://stackoverflow.com/questions/3215395/ca1500-vs-sa1309-which-one-wins – Sheldon Warkentin Feb 02 '12 at 18:11
2

I do not like underscores for variables. There is no need to prefix a variable with an underscore. Using `this`, you can easily reference and find all of your private field variables without mucking them up with an underscore. – Adam Spicer Feb 02 '12 at 18:32

score 3 · Answer 2 · answered Feb 02 '12 at 18:05

3

Ultimately, the only universally accepted naming convention for C# is the following:

Namespace names are PascalCased
Type names are PascalCased
Public and protected members of types, including methods, properties, and fields, are PascalCased

Additionally, it's generally accepted, albeit not universally, that:

Method and constructor parameters are camelCased.

The rest vary wildly enough that it doesn't really matter. As long as you adhere to the above, you're golden.

answered Feb 02 '12 at 18:05

Randolpho

55,384
17
145
179

In order for constructor parameters to be camelCased, the class would have to also be camelCased. I don't think Class names are camelCased. Warning 1 SA1300: class names begin with an upper-case letter: restartability. – Chad Feb 02 '12 at 18:29
constructor *parameters*, not the name of the constructor. Constructors are just special methods that have the same name as a class. I'm talking specifically about the parameters to those methods. – Randolpho Feb 02 '12 at 18:35
This seems to be a minority view, but having protected methods be camelCase makes logical sense to me. If I have a variable MyClass x, obviously I can only call public methods, e.g. x.DoSomething(), so I would make anything that can't be called externally be camelCase... i.e. protected methods If I have MyDerivedClass : MyClass, and a variable MyDerivedClass y, I wouldn't be able to call y.someMethod() if someMethod() is protected and defined in the base. – KevinVictor Feb 22 '22 at 20:51

score 2 · Answer 3 · answered Feb 02 '12 at 18:02

Starting local and member variables with lowercase is common. Where I work we have chosen to prefix member variables with _, but that is just a matter of convention.

I would write it like this:

public class Restartability {

  private readonly string _sourceFile;

  public Restartability(string sourceFile) {
    _sourceFile = sourceFile;
  }

  public string SourceFile {
    get { return _sourceFile; }
  }  

}

Or using property shorthand:

public class Restartability {

  public string SourceFile { get; private set; }

  public Restartability(string sourceFile) {
    SourceFile = sourceFile;
  }

}

This doesn't make the backing variable read-only, but the setter is private so only code inside the class itself can set it.

Warning 1 SA1309: Field names must not start with an underscore. The shorthand changes the read only property to read\write — Chad, Feb 02 '12 at 18:06
It is only writable from inside the class not outside as it is marked private. Turn off the warning in FxCop IMO. — Fen, Feb 02 '12 at 18:12

score 1 · Answer 4 · answered Feb 02 '12 at 18:02

1

When I have private and public properties that have the exact same name, I name the private one with a _ at the end. I think it's a good practice and we all do it here in my company. We all are .net developers

answered Feb 02 '12 at 18:02

Eric Frick

847
1
7
18

Not a bad idea, until this convention becomes as popular as prefixing module level variables with an _ and then FxCop catches up to prohibit this to. – Chad Feb 02 '12 at 19:10
Corerction: StyleCop is on to you already. Warning 1 SA1310: Field names must not contain underscores. i.e (anywhere) – Chad Feb 02 '12 at 19:21
Personally, i had never used this software. I will totally take a look at it! Thanks for the advice – Eric Frick Feb 03 '12 at 14:50

score 1 · Answer 5 · answered Feb 02 '12 at 18:02

1

The most common naming schemes for fields of C# objects are

A "m_" prefix: m_sourceFile
A "_" prefix: _sourceFile
No prefix and a fix of using this. to reference or just plain old sourceFile

answered Feb 02 '12 at 18:02

JaredPar

733,204
149
1,241
1,454

score 0 · Answer 6 · answered Feb 02 '12 at 18:07

If you're starting out in C# and thinking about coding style and convention I really recommend a book called The Elements of C# Style!

I also recommend getting yourself a copy of Resharper and the stylecop for resharper plugin

Coding style is a contentious issue amongst developers and there will no doubt be may differing opinions posted here, but the one rule I feel is more important than any is whatever style you use, be consistent.

A very good developer once said to me, no matter how big the project is, it should all look like it was written by the same developer on the same day.

score -1 · Answer 7 · edited May 23 '17 at 10:32

-1

Modern IDE's should have the capability to highlight class specific variables and therefore _ or m_ or this. should be redundant. See: Visual Studio identical token highlighting for more information on this in VS.

edited May 23 '17 at 10:32

Community

1
1

answered Feb 06 '12 at 16:41

oliveromahony

471
4
19

C# naming and casing conventions

7 Answers7