One of the least glamorous and most often overlooked factors in website design is code formatting — the layout, structure and syntax of the JavaScript, HTML or other commands that define a website or mobile app.
For the majority of developers relying on software tools such as Dreamweaver for code writing, code formatting is a function of the authoring application; sometimes, user customizations for font colors and faces, indenting and more may be available, but the appearance of the resulting code is ultimately up to the software producing it.
Fortunately, one simple solution to this problem is at hand for coders working in an internal production environment.
Developers that write code by hand have far more leeway, however; scribbling wild and free, often without consistent commenting, tabbed indentations, or other features that ease the production process — as well as ongoing code maintenance and updates.
While these two extremes can be startling in their diversity, the importance of code appearance is much more than aesthetic, especially when considering its distribution and longevity in the wild: for example, a snippet of code intended for personal use can be written any way that will function — while code that is intended for commercial (or free) distribution, where other developers will need to read, understand and edit it, should be as “clean,” commented and consistently formatted as possible.
The WordPress Codex (codex.wordpress.org) offers a formalized coding style guide for theme and plugin developers, containing recommended best practices for indentation, line spacing and more, with an emphasis on catering to the needs of other, future users.
Sadly, producing code such as a website theme to this specification doubles its size in comparison to more condensed approaches. This is demonstrable when running code through one of the many online formatting and optimizer services, where a large CSS file may have its file size halved, simply via the removal of tabs and extraneous white space.
Sure, it will load nearly twice as fast, speeding up your site, but when it comes time to edit that file, it may be much more difficult to find the relevant code portion to modify — a situation that will dramatically worsen when it’s compressed JavaScript you’re eying.
Fortunately, one simple solution to this problem is at hand for coders working in an internal production environment, where ease of maintenance and legacy protection is as important as small file sizes: have two copies of every file.
By developing and updating your code in well-commented and properly formatted chunks, using consistent line spacing, generous white-spacing and indents, and color keys for various sections — but then compressing those file’s structures before uploading, you will have the best of both worlds: fast, streamlined code that is easy to read and maintain.