Two C# naming conventions: What do you think?

Question

I have two specific C# coding conventions I've been practicing with mixed feelings. I'd be curious to hear what people think. They are:

#1. Name instances after the class it's an instance of, camelCased

#2: "Matching property names"

Here's the rationale:

#1. Name instances after the class it's an instance of, camelCased

I use this as my default setting for naming convention. Of course, there are exceptions. But used consistently it dramatically improves code clarity and maintainability. The code looks like this:

var dataConnection = new DataConnection();
//not: var dataConn, dbConn, sqlConn, myDbPickOfTheDay etc.

FileInfo fileInfo = new FileInfo();

Timer timer = new Timer(); 

//etc.

I'm at the point where code like this causes me physical pain:

DataConnection dbConn = new DataConnection();

I can't stress enough how this convention has taken away the pain and anger of the variable name game.

This convention is in sharp contrast to attempting to name things in ways that try to indicate what the instance is doing, which amounts to trying to creatively embed the business case in code. Code has a way of getting refactored to the point where those original names are misleading at best.

To me this convention is gold. It also prevents the horrible practice of slightly tweaked variable names for the same thing.

An example of this convention in practice is:

class Person { ...
   public string FirstName { get; set; }

//and then
var person = new Person();
person.FirstName = firstName; //where firstName comes from somewhere else.

Very easy to read. Very boring. Boring is good when it comes to maintaining code.

However, this convention leads me to #2:

#2 "Matching property names" ( for lack of a better title )

Here's an example:

public class ShoppingCart { ..
  private Item item;
  public Item Item {  //<---- ?
  get { return this.item; } ...

The compiler is perfectly happy with this. And, in fact, it exposes a very nice interface:

//notice how tempting it is to just say "ShoppingCart cart ... "
ShoppingCart shoppingCart = new ShoppingCart();  
shoppingCart.Item = item;

Now, the alternative is to be creative -- You actually need to drum up two good variable names for Item: the public property name and the private member variable name.

How many times have you seen this and just want to retire immediately?

 public class ShoppingCart { ..
      private Item cartItem;
      public Item ShoppingCartItem { 
      get { return this.cartItem; } ..
  ///....
  ShoppingCart userShoppingCart = new ShoppingCart();
  userShoppingCart.ShoppingCartItem = userSelection;

I feel strongly enough about convention #1 that I think I can live with #2.

What do you think ?

Answer 1

Obviously, you can't name every System.String in your project string*, but for things you don't use a lot of, esp. things you only need one of, and whose function in your code is obvious from its name, these naming conventions are perfectly acceptable.

They're what I do, anyway.

I would go with a more specific name for, say, the Timer object. What's it a timer for? But I would definitely name a DataConnection dataConnection.

*Even if "string" wasn't a keyword...

Answer 2

I do 1 all the time and find it very readable. I'm on the fence with 2. I find it confusing in certain situations, mainly because it's hard to distinguish the type from the property due to the identifiers being identical.

Answer 3

in case you were not aware and if you care , C# already has a naming standard

http://msdn.microsoft.com/en-us/library/xzf533w0(VS.71).aspx

Also, looking at your conventions again ... here's some more suggestions.

• fileInfo looks pretty next to FileInfo but it has no meaning other than it's type which I can quickly get by mousing over the type or in intellisense. I would suggest naming your variables with meaning and some context if available. remoteWebServerLog, localWebServerLog, or even localWebServerLogFileInfo if you like the type in the name.

  If I can hand off any advice from coming back to code you've written 6+ mos later. You will be scratching your head trying to figure out and track down what the heck all your dbConn and fileInfo's are. What file? What db? Lots of apps have several dbs, is this dbConn to the OrdersDB or the ShoppingCartDB?

• Class naming should be more descriptive. Wwould prefer ShoppingCartItem over Item. If every ListBox, DropDown etc named their collection items "Item" you'd be colliding with a lot of namespaces and would be forced to litter your code with MyNameSpace.ShoppingCart.Item.

Having said all that ... even after years of coding I still screw up and don't follow the rules 100% of the time. I might have even used FileInfo fi = ... but that is why I love my Resharper "Refactor->Rename" command and I use it often.

Answer 4

Convention #1 can become confusing. If you were to have two FileInfo objects in the same method-- say a Source and a Target-- you'd need to deviate from the convention in order to name the two.

Variable names should be mnemonic-- to indicate to the casual observer the intent of its use.

Perhaps you'd be happiest with a combination of the two conventions... such as sourceFileInfo and targetFileInfo, per this example.

Answer 5

I follow convention 1 all the time. Although, I do add an additional qualifier if there are two objects side by side.

But having said that, making this convention mandatory may be problematic:

1. In a certain context cart may be a good enough name for a ShoppingCart object (if, for example, there is no other 'cart' in the same function to be confused with).
2. Sometimes the convention may completely obscure the purpose of the declared object. For example Window scoreBoard = new Window() says that we have an object which is indeed a Window but is being used as a scoreBoard. Very expressive. But following convention 1 you'd have to write Window window = new Window() which totally hides the intention behind this window.

So I'd say use this naming idea everywhere except when it hinders meaning or appears unreasonably demanding.

About convention 2, I totally agree. Keeping property names succinct and letting the object name complete the full meaning of its invocation is an elegant thing. It works perfectly with well named objects. So there's little reason to be shy of using it.

Answer 6

I would normally follow convention #1, although for long class names I tend to just use the initials of the class. If I am referring to more than one object of the same type then I would pre-pend the type name with a name indicating which one it is or what it’s used for.

I quite often use convention #2 if it makes sense. There is nothing worse than having something like the example you listed of cart.ShopingCartItem, the very fact that it is a property of ShoppingCart makes that part of the property name totally redundant. However I would quite likely name the class ShoppingCartItem and the property Item. Item is a little too generic a name whereas ShoppingCartItem tells you what kind of item you are working with.