Today the amount of code developed per project has dropped dramatically from the days of Cobol. Microsoft routinely bundles in a few thousand pre-coded classes along with its Dot Net Framework in the attempt to reduce coding largely to drag and drop. Organizations all over have bought into the benefits of adapting ready packaged solutions over custom developed software. But coding is not yet an ‘endangered’ job and is not likely to fade away anytime soon. So standards in coding continue to be relevant at least for now.
Many coders are young freshmen from college. They may not yet appreciate how coding realizes, on the ground, architectural objectives set out for the software. Coding standards, for them, are much simpler ready recipe to follow without deep knowledge of these architectural objectives. Adherence to the standards thus mitigates the risk of inexperience or lack of higher-order knowledge.
There is a second source of risk. Today, code is no longer monolithic – it resides all over the place, inside the browser, server pages, beans, cgi code, apps server, sql procedures, xml, css, etc. These are different technologies, each commanding its own best practices. You tickle anyone of them in the wrong place you are in for some grief. For accomplishing a small function, code from many of these fragmented technologies must be threaded together. Things never got simpler under the hood! In such a mixed-up scenario, pre-packaged wisdom by way of standards or best practices reduces the risk of inappropriately using these technologies.
I still recall from past how someone in a remote support team, working on an emergency patch, caused a blood bath by writing a short sql snippet disregarding some set norms, that inadvertently wiped out data partially from the end-user’s production server.
OK, that’s enough of reasons to have standards and best practices. So, what’s the point?
When I interview developers, I quiz them on coding standards. Most organizations have coding standards that run into several pages. We seriously think that any developer allows himself to be guided by these pages of do’s and don’ts every time he keys in a snippet of code? Fortunately checking adherence appears to be more manageable with tools available now which can zip thru developed code against a few hundred coding rules and spew out the violations. The rules could even be customized. But can you imagine the effort involved in removing these violations? The only way to operationalize these voluminous standards for real would be to put together a tool that would clean up the code generated by the developer automatically or in an assisted mode or have the IDE enforce these standards while the code is being developed. To expect the developer to manually adhere to the standards is impractical. If the organization’s Quality System or the Process Model expects this adherence or if someone out there claims all these pages of standards are scrupulously adhered to in the manually written code…
There is another serious angle to these voluminous standards. These standards rarely have architectural attributes as one of the keys. So when I ask ‘What parts of your organization’s coding standards help you to develop an application with very low number of defects?’ most often candidates have heard it for the first time. We all know that an application cannot be developed with equal emphasis on some 20+ architectural attributes. The question of classifying the standards by architectural attributes and prioritizing them for a given application is real.
It is common to find the standards keyed by the subsystem covered. Of all standards, those covering the database subsystem are most crucial because any damage thru incorrect coding in those parts could be permanent, affecting large number of users and recovery painful. With most other subsystems, the worst case may be an aborted user session. External Systems, it is assumed, are capable of rejecting wrong usages.
It would be interesting to contemplate on other possible keys (technology is another obvious candidate).
Later we will look at some real life examples of what goes into the coding standards and how to put some real bite into them.