I am starting a new, huge project soon, using some different tools than I have used before. So the first thing we need to do in this project is to come up with new standards for these new tools, right? No.

Understanding the overall scope and desired results, requirements are first, then a high-level design and architecture plan including what tools one expects to use.

Standards however, are something that you should be in place before you start creating stuff.

Why do standards matter?

Think of it this way. Go take a drive in your car, then go rent a different model of car (assume an automatic transmission of some sort). Something so completely different from your personal vehicle, but still a car that drives on the same side of the street as they do in your country. There are certain things that are very standard that you will notice in 99% of the vehicles out there. You will see a steering wheel, and 2 or 3 pedals. There will be a speedometer and fuel gauge that you can easily see between the spokes of the steering wheel. With these standards you can drive almost any other vehicle out there with little trouble.

However, think about all the other details like how to turn on the lights. wipers, open the hood/bonnet, turn on the music, navigation, cruise controls, gear shift (I am still not quite used to the dial in my 4 year old car!) etc. When you get into that rental car, how many times have you been sitting there in the rain trying to figure out how to turn the wipers and lights on?

While these are generally not safety concerns (which is why they haven’t been standardized), they do illustrate that when things are standardized, they are far easier to use without thinking.

Coding standards make using software easier

There are so many things you ought to standardize on at least at the project level, but ideally at the software development team level for the same type of reason. If you know what something will be named, you don’t have to think as much. The more a name is referenced, the more likely you will care. Column names in tables are the biggest example of this. Take these two table declarations (pseudocode):

CREATE TABLE Orders.Header (
   HeaderId int PK,
   nm   nvarchar(20)
);
CREATE TABLE Orders.Det (
    Id int PK,
    Nm   nvarchar(20),
    HId  int FK (Orders.Header)
)

Will this code work? You bet, will I have to look up the names of the columns every time I do a query? Same answer.

Everything should have a standard

While that heading sounds Draconian, it really isn’t meant to be. “No standard” is a standard when it fits your needs. But the more you standardize on, the easier things are to search for in text.

Things like:

• Object\Module Names – Words are spelled out, or there are standardized abbreviations
• Prefixes – Non-customer facing code might have standard prefix if they are in compiled code
• File Names and Prefixes – Some naming scheme that everyone knows, even if it not standard (you can always map tools to look for .NameFile instead of .txt, or just incorporated it into the name like Purpose_Namefile.txt
• Folders – keeping a proper folder hierarchy is so very useful when you need a file

And so many more things. Just note, these standards don’t need to be rigid in nature, just defined well enough that they make sense and can be followed with minimal effort.

Why waste the time?

Table and column names may make sense (though they are also notoriously difficult to actually follow too), but customers, users, etc will never see most of the names you set in your code and files, so is it worth it? In a word, yes. Or why did I write this blog?

There are two values and they both save FAR more time in the future and later. Once you get used to a standard, it costs almost nothing to follow the basic standards. Then you get two major wins:

Code reviews (by people or tools) – anything out of standard will be immediately noticeable rather than people having to question “What is this object and what does it do?” and you can spend your time seeing if it does what it says based on the name.
Searching for stuff – searching for stuff by name is a lot easier if you can easily guess what the thing you are searching for would be named.

Conclusion

Setting standards as much as you can for your coded objects, files, databases, etc, etc can make working in your code base a lot simpler for your team over time. Sure it will take a bit of time to set up standards, and a bit of time to get used to them. But you will thank yourself year after year.

Well, until you come up with a new standard that you wish you could implement instead of the one you have been using for years.