Coding Standards and Coding Principles

I can already hear the silent grunts and see the invisible grimaces as you read the title of this post. We have all been burnt and have experienced lots of unpleasant encounters with coding gurus who frape us with coding standards.

The first time someone code reviewed me, I felt like someone had a grip on the valves of my heart and was squeezing it like a stress ball. “Why are your variables not declared in one place, you are not allowed to use that function, you wrote TOO many comments.” I never even knew there was a thing such as too many comments.

Everyone universally agrees that coding standards are a good thing; standards give meaning to measurement and help create more stable derivatives. Measurement help grade performance, performance indicates skill and improved skills lead to promotions. But what if you are in a start-up, building a prototype and already the CTO…how do you get promoted or how much do you plan on deriving the next version from the prototype?

This situation is not unique to us; most initial stage startups are similar. There are one maybe two developers…given 3-4 months to build a prototype. Very hectic timetable, you obviously want to build something which can be reused for later versions, so good coding is important. But does it matter if all the variable names are in alphabetical order?    Is it important that each function has a good reason for being public or private?

How do we draw the line and where do we draw it? Is there a way to compromise?

Lots of people say, “No way, no compromise. There is good code and bad code and nothing in between.”

Unfortunately that line of thought costs too much. So we focus on what we call ‘coding principles’ and not coding standards.


Principle 1: Use frameworks when possible; utilize the API to the maximum. So we write less code and there is less to worry about.


Principle 2: If it’s code that is simple, something that takes roughly the same time to copy/modify as to rewrite. Don’t worry too much about coding standards in that case. (This automatically implies breaking up the work into lots of functions, which is good OOP design anyway)


Principle 3: If it’s a complicated section. Discuss with colleagues on how you are solving the problem. Make sure the team knows what that section of that code looks like. Make sure this section of code is highlighted in some way for reuse later. (No black boxes, but we maintain boxes which do lots of useful things with a lot of care).


Principle 4: Version Control Systems is your friend. Use it!


Principle 5: Use your own personal standards. Most of us have a built in way of standardizing code, we arrange functions in a certain way or name variables in a certain way. Don’t fight it…it organizes code quite nicely. If you are the only one who is going to go through the code again…what better way to organize it!


Basically all I am saying is, coding standards are like good manners.

You need them most at public places, when you are at home by yourself with a plate of pasta in front of you and cannot find a clean spoon…no one will know how you ate the pasta!