.netnamingconventionscasing

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 your 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?

Solution

  • 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.