Does naming conventions make better maintainable code?

I like to give my variables, methods and objects descriptive names. Obviously not going overboard, but let me give you a couple of examples.

public class Account
{
    public decimal Balance { get; set; }
}

Account account = new Account();
account.Balance = 1000;

Some people would opt to go for the following, which really does not make sense to me, unless you are a lazy typist.

Account acc = new Account();
acc.Balance = 1000;

The problem is when you have logic with these abbreviations. You get extremely confused as to what is happening.

Imagine the following objects.

public class Account { public DebitOrder DebitOrder { get; set; } }
public class DebitOrder { BankDetail BankDetail { get; set; } }
public class BankDetail {}

Account acc = new Account();
DebitOrder do = new DebitOrder();
BankDetail bd = new BankDetail();

if(acc.DebitOrder.SomeProperty == do.SomeProperty)
{

}

The readability goes down the drain. There is always the argument of intellisense and just hovering over y开发者_如何学编程our variables to see what type they are, or what they are. Readable code, makes for easily understandable code.

Does naming conventions make better maintainable code?

Yes, of course naming conventions make better maintainable code.

That is why, in your first day in a programming class, the lecturer will smack you if you call a variable x, or i...

You have to remember that names of variables/methods/class, etc is purely for the programmer, as when compiled these will only be addresses to memory.

you have to try and use a good balance of readable, self explanitory naming conventions, good comments and well structured code to make better maintainable code.

Yes, for any variable that doesn't have a very limited scope.

When the scope of a variable is very limited, and when the code revolves around that variable, you can get away with a throw-away variable name.

For example, a counter in a loop can have a simple name if the loop body is small and the counter doesn't rellay have any other meaning:

for (int i = 0; i < 10; i++) arr[i] = 0;

Lambda expressions can be more readable using a short name:

var items = source.Select(n => n.ToString() + ".");

However, when using short names don't try to abbreviate something. If a single letter or a well known abbreviation doesn't do it, you can just as well go for a longer name.

For example, using n for a numeric value, as in the lambda exression above, would work. Using something longer that is still an abbreviation, like itnum or itmid makes the name carry more information, but not enough to be useful, so itemNumber or itemId would be better.

When I program in languages like C#, I'll often give my variables short names just because it's easier to type and I can fit more code on the screen. This works well when you're in the zone and know exactly what everything is, but for exactly the reasons you mentioned, it would be very confusing to an outsider, or even yourself a few hours later. Nice IDE's make it super easy to rename variables, which I would definitely suggest doing before walking away from your project for the night, or certainly before sharing it.

Guffa raises some good points about when short variable names are appropriate.