Developing and Enforcing Coding Standards
- Problems Due to Lack of Standards
- Researching Existing Standards
- Enforcing Coding Standards
- Coding Standards Table of Contents
- Specific Coding Standards
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Problems Due to Lack of Standards
If ever you need proof that clearly defined and enforced standards are required on any IT project, all you need to do is look at some of the problems caused by major IT projects not having such standards.
Even IT projects that are aimed to enhance industry standardization have problems. For example, the differences between the way "standard" HTML was implemented by various browsers kept developers very busy for some time. The problems caused by different implementations of Java virtual machines have been numerous. The hassle of getting the same piece of code working on many different operating systems (even when the operating systems were developed by the same company) have continued to dog the IT professional.
It's maddening how many problems have arisen on heterogeneous web projects that I've worked on because copying the same file to two different operating systems can result in two very different filenames (for instance, myFileName.htm might become MYFILENAME.HTM) or because the same filename can exist with two slightly different extensions—myhtmlfile.htm and myhtmlfile.html are both valid (but possibly very different) HTML files.
Anyone who has tried to convert an HTML file into an XML file will understand my frustration that the original HTML tags were not case sensitive, whereas XML/XHTML files are picky about case. As a "hand coder," I've also lived to regret every time I didn't close an HTML tag and didn't put quotes around my attributes because I didn't have to!
If problems just described can happen even when the whole industry is attempting to enforce standards, it's not difficult to imagine how many problems can arise on any one project—especially if no coding standards are enforced. In his book Code Complete: A Practical Handbook of Software Construction (Microsoft Press, 1993), Steve McConnell provides some great examples of the kinds of problems that arise on projects that don't sufficiently enforce coding standards.
While most of us don't have direct control over emerging industry standards, we can limit the problems caused by issues such as these—and also by mistakes made in the development environment—by developing and enforcing effective coding standards.
For example, effective naming standards will ensure that capitalization of filenames is uniform and that filename extensions are consistent, so that should filenames or extensions ever need to change due to project or industry changes, a quick script can uniformly alter all code in the same way.
My problem with converting HTML into XML could have been averted had my HTML tags been subject to stricter standards. To simplify translation into XML at a later date, all tags should have been lowercase. Other coding conventions that would have aided the transition from HTML to XML include enforcing the requirement to close each HTML tag (by default, not all HTML tags have to be closed). If you always created your HTML files using a tool such as FrontPage or Dreamweaver, this wouldn't have been an issue; these packages enforce naming conventions. Some tools are now available to help you with the conversion of hand-coded HTML (a bit late for me)—Macromedia provides such functionality, for example.
Because progressions in technology such as that from HTML to XML can cause consistency problems, it's a good idea to try to anticipate such problems wherever possible. The technology industry is constantly moving to bring different standards and platforms together—in the past, for example, this tendency affected the development of Netscape and IE, COM+ and CORBA, Java and VB/C#, and other technologies—and now it seems that .NET and J2EE may be closer to one another than they might seem on the surface. Bear this possibility in mind if your organization may eventually develop code for both platforms or either platform. Coding standards that work for one platform but not the other might require a lot of rework in the future.