Why I Write Complaint Code

A few weeks back a colleague presented me with an interesting question. He works with an Oracle database and PL/SQL (a programming language deeply tied to Oracle) to create website applications. As he wasn't too familiar with HTML and other modern web content trends, he often ran into issues with different browsers. He used the w3c compliance test as part of his troubleshooting process but never understood what compliance was useful for, especially as his HTML, which would display and work properly, rarely passed the test.

To begin, the term 'compliant code' is thrown around quite a bit. I'm using it in this post to describe xHTML/HTML with no open tags, correct tag names, and no outdated coding techniques or methods. Also, I tend to keep CSS and Javascript in external scripts to make my code easier to read and update, but this is not necessary to pass the w3c compliance test.

I have always made my code compliant and leaned towards xHTML transitional or strict with my website projects without really thinking of a reason behind it. My original experience with website programming was under a strict teacher who was very adamant on clean, compliant code with external stylesheets and scripting. When my colleague asked me a reason behind my coding style, I had to think a bit on it (he did have over two decades of experience on me) but eventually came up with three solid reasons for making clean, compliant xHTML coded websites.

The first reason is probably the most obvious: cross-browser compliance. You don't need to have compliant, well-formed background code to make your websites look and work the same across the many different browsers available, but it does help. Also, while some browsers, like Mozilla's Firefox, will auto-correct invalid code so it appears correctly, this action eats up processing time for the user's computer.

Valid and well-written code is also easier for future programmers to update. This reason extends further then just xHTML/HTML, though - server side and client side scripts also benefit from following conventional rules and structures. I've worked on muddled scripts several thousand lines in length with no clear design for long periods of time looking for a single variable or query that needed updating. Also, trying to sort through a mess of tags and mixed indentation is not an easy task either. Following simple conventions and compliance rules will make your code easier to scan and understand for yourself and future coders.

Finally, and the main reason I check my own sites for compliance and well-formed code, is pride. Most websites I work on may take days, if not weeks, to finish. Spending that much time on a project and launching it to the public platform of the internet with non-compliant and messy code is simply lazy. While it may take extra time to debug and clean up background coding, I feel that it's a necessary process of the web development process.

I'm not sure if my colleague will start writing stricter code or not, but his question gave me time to reflect on my personal web development habits. Hopefully it will give another web developer out there an opportunity to reflect on their own habits as well to either reevaluate or confirm their own methods.