Naming Conventions and Clarity
(May 01 2007 - 08:46:42 PM
by Timothy Khouri
) - [print article
Just like a programming language has a standard set of rules for how to accomplish a desired task, so does development and design in general. While syntax errors are quickly brought to your attention thanks to your compiler, most developers go for years before learning about proper development standards. This article will briefly discuss the small but significant area of naming conventions and clarity.
Bad Coding Habits
One of the first things you may notice when you join a team of developers that you have not worked with before is their "coding style." Usually this is accompanied with bad coding habits that come from bygone days. They may not realize that their code is hideous, but you recognize it right away. How do you know it's bad code? Because you have no idea what it's doing.
A code file strewn with hungarian notation and rediculous prefixes will slow down your development and will nearly kill the progress of anyone else trying to work in your code. We realize that you can't spend all of your time going back to fix your previous work, but here are a few things to avoid when starting your next bit of code.
objHabit to Avoid
Hungarian notation is highly un-semntic because instead of a variable's name representing data, it represents the "type" of data that is contained there in. Example: a variable containing a person's whole name might be "FullName", but using Hungarian notation, you could call it "strFullName." Who is questioning the fact that "Full Name" is a string? No one! But what you have now done is pointlessly named this variable something weird so that the next developer behind you (or even yourself) is going to have to hunt to find what he needs.
public string strFullName = "Timothy Khouri";
public string FullName = "Timothy Khouri";
wHaT cAsE dO i UsE?
The next common standard you can use is that of casing. All public methods, properties and fields should be ProperCased (also known as PascalCased). All private or internal fields should be camalCased where the first letter is lower cased and all subsequent words are ProperCased. Abbreviations follow an interesting rule: If the abbreviation is two or less letters, then they may all be upper cased (the first would still be lower if it is private); if there are three or more letters, it is treated as a normal word. Examples:
private string fullName;
public string FullName
private int iD;
public int ID
public string GetHtmlData()
Clearly Define Your Objects
The last point that you want to be sure to follow is that of being clear with your variable and function names. Even inside your function body, you should heavily avoid throwing together a meaningless variable name, but should try to define each object as to what it is. This will make your code more readable, and you will be thinking in terms of objects as apposed to thinking in terms of specific object types.
There is much more to standards than these simple guildlines, but starting here will help you to advance as a developer. You will begin to quesiton why you did something a certain way and will discover how to do things the right way.