Not many people like to be told what to do. I sure don’t. And if someone is telling me how to do my job, I am am likely to become that much more defensive. So I understand if I ruffle a few feathers with the following ideas/tips/guidelines. Go ahead; cuss me and insult my heritage. If you can get past my absolute arrogance and actually consider these five ideas, you may be able to improve your websites or decrease your website maintenance workload.

From least likely to most likely to anger my audience:

Use includes for html or code

This idea is hardly new. The majority of websites on the Net are already going this route. If you have a site that doesn’t utilize a variety of includes, here are a couple reasons why you might consider a change.

• Moving code and/or markup into different include allows us to organize by type. Navigation is here, header markup there, etc. Same concept works for code.
• Reusing code is cool. It is even cooler if pasting a single include into your source file is the only labor involved.
• Utilizing an include across many web pages allows the webmaster to make a change to one file and be able to affect the many pages that include it.

Utilize .css file when possible

This is really an extension of my first tip. Having a single file to define styles for the entire site is really a no-brainer. This may feel a little intimidating to those old school webmasters that have traditionally handled styles via .html markup but most of the web world has already jumped on this train. In addition to the benefits listed in the first tip, additional benefits are:

• No styles in header or inline markup to congest code (and get in the way of Search Engines searching for content.)
• Smaller file sizes. There won’t be a huge difference, but when applied across the entire site, it will be a measurable difference in bandwidth requirements.

Choose search engine relevant file paths

Instead of www.non_existant_site.com/vx133.htm, try www.non_existant_site.com/vortex_generator/model_133/specification.htm. Now I’m stepping on some toes. Some webmasters may believe I am asserting that they are making poor choices in folder or file names. I wouldn’t say all of these choices are necessarily ‘poor’, but sometimes they can be improved. Most webservers give us lots of latitude in choosing our own path and filenames. Despite this, here are three reasons that support giving your pages more descriptive filenames.

• Search Engine algorithms are kept secret. They also change frequently. Despite this, many SEO experts believe descriptive file paths may help your site and page rankings for relevant terms.
• A Search Engine user is more likely to choose your site from a long list of similar results if they can read what they are searching for in the file path as well as the page’s description.
• Dealing with many sites or being in a position to delegate work to subordinates are just two reason why it may make maintenance easier in the future if the file path and file name guide the developer to the correct content.

Place commonly utilized functions/objects in a reusable ‘toolbox’

As a web developer, I am usually implementing a website or supporting code that is not completely different from a previous project. Yes, I know, we all want to feel like we are creating the latest, greatest, can’t live without it new fangled whiz-bang website. The sobering truth is that 99% of the time, it just isn’t so. Because my tasks are similar from project to project, my code ends up being similar also. My next tip is one that may cause some rebellion among some of you. I’m proposing an idea with two thorns.

This idea is to create and use a ‘function toolbox’. It matters not what language or environment you are developing for. Over time we all develop functions or objects that can be utilized on many projects. My idea is to drag this toolbox from project to project (assuming similar environments). The thorns, however, are as follows. The first is that, as developers, we are reluctant to bring more code to the party than is necessary. The second is time management. I am proposing that, when we create a function or object, that we make it somewhat generic in it’s use. If we find, later, that it can be extended to add more functionality, that we do so instead of creating a new function. This type of creation and modification takes planning and a slightly larger time investment than might otherwise be expended. The payoff comes down the road. Here’s how:

• The re-use of code speeds development. If we don’t have to re-invent the wheel, we can spend that same time creating something new, like other parts of the website that will display the ‘wheel’.
• Memorize functions. I have a template function in my toolbox that allows me to quickly populate .html templates. Because I use it regularly and have memorized it’s variables and output, I can quickly add the function call to my code.
• Refinement of the reusable code. As we use and re-use these tools we will, over time, realize ways to make them faster, smaller, more powerful, etc. As they are refined over time they become that much more valuable.

Congratulations if you’ve made it this far, but the gloves are coming off.

Stop using tables for layout

I believe most old school web designers have swallowed their pride and dispensed with the practice of using tables for layout. If not, this tip might be the one that raises some folks blood pressure. I’m sorry (kinda). We’ve all heard it before, tables are for tabular data, css style should be used for layout. Here’s what everyone agrees on:

• CSS layout yields smaller files, faster page loads (css styles are smaller than table tags). Fast is good, right?
• Utilizing an included .css file allows consistent layout due to shared CSS code. Maintenance is simpler, too.
• Today’s users expect better. CSS and today’s browsers allow better access to mobile devices and visually impaired users.
• CSS is generally all in an included file. When Google (or any other SE) spiders your site the less markup they find the better the content to code ratio will be.