Thursday February 24, 2005

Codex.

In the years I have spent writing code for the web, I have seen thousands of pages of source code. No matter how “advanced” a web author you may be, you know you still do it. Whenever I see a well-crafted website (or, alternately, an abomination dressed in HTML), I just have to right-click and View Source (and usually CSS, too). In doing so, I have been endlessly fascinated by the many variations in code formatting employed by web designers.

I’ve been thinking about this more often lately, as I have been working on various projects that have more or less required me to work off of others’ pre-existing code (more on that later), including HTML, CSS, and Actionscript. In the case of working off of other’s code, there may be absolutely nothing wrong with it at all. In reference to this latest project, it’s absolutely top-notch. But it’s those subtle differences in syntax that make all the difference. I think it’s safe to say that most designers could recognize their own code—or code using their formatting style—on sight.

For my own work, I have found that I work best in HTML by using a model I call the Tab Hierarchy. I see a form of it used on most designers’ websites I visit (when it’s not obliterated by CMS output, that is). I interpret the format to mean that for every piece of code that is nested inside a greater governing element, it gets an extra indentation from the Tab key:

<div id="container">
      <div id="nested">
           <ul>I'm a list!
                <li>I'm a list item!</li>
           </ul>
      </div>
</div>

Now that’s mostly your basic Dreamweaver format, but stuctured a little more carefully as code becomes more and more nested. When coding CSS, I find that I use one of the following formats, depending on how many attributes I am using:

#example {
      margin: 0;
      padding: 0;
      border: 0;
      }

#example { margin: 0; }

It’s pretty standard fare. But then there are the the endless formatting variations. Which properties do you list first? Do you follow a specific order? Do you group selectors alphabetically or by function? Do you indent the trailing }? The questions are endless, I suppose.

What I’m really driving at, specifically, is the reasoning behind how and why we format our code the way we do. Did you learn it from one of the ‘masters?’ Did you start there but modify the format to make it more sensible to your own sense of organization? For the most part, I see code that is largely identical in format, but there is usually at least one little quirk, if not more, that makes someone else’s code immediately discernable from our own.

Got any formatting tricks up your sleeve? Code-related organizational methodology? I’m not so much interested in changing my ways as I am in discovering why we format code the way we do. Maybe the answer is a no-brainer: because it works? Do share.

A quick note about posting code in comments:

Due to a teeny bug, some HTML is accepted into the comment form, even though it should not. When inputting code, even when wrapped in code tags, it will not appear as code. Please “break” HTML tags by adding a space after the opening bracket, a la < div>. Indents can be added using 5 consecutive &nbsp;’s. CSS code is unaffected. When in doubt, check the Preview.

And please, no comments about how Wordpress doesn’t have this issue. ;)

You may also post a screenshot. Images may be no larger than 375 pixels square. See Textile Help for image code.

Comments


Abel Rios » 5140 days ago #

I’m obsessed with code-formatting. I say obsessed, because I’m so used to it, that even when typing letters in word (etc.), I catch myself tabbing after every line. It’s more than just a habit. It’s proper behavior. If you’re writing code, help yourself, and do the following:

Comment appropriately!!! I can’t stress this enough. Code is already hard to read, so save yourself the trouble and comment on it. I can’t stand to look at unformatted code…it hurts the eyes! :)

Tab appropriately, where you can. This helps you in finding everything in your document. Whether it be Actionscript, HTML, CSS…an appropriate tab structure can save you so much time. Plus, it just looks cool!

gb » 5140 days ago #

I just got through with a major redesign of my site, and for a long time, I worried about the formatting of the code. For the most part, that still remains true, but as it came down to the wire before the relaunch, I found myself ditching my grouping methodology and just tacking “fix it” css at the end of my style sheet. And as you mentioned, a CMS really kills most hopes of overall nicely formatted markup.

Maybe one day, when I have nothing to do, I’ll straighten it all out…

Feaverish » 5140 days ago #

The single most important trick that I use to understand all the nesting and hierarchy issues is to make a visual model. I learned it over at Malarkey’s site, in this article. I just fire up InDesign, make a big box for the site’s body, and work my way down the site’s code making boxes for each element (see the examples over at Malarkey).

I’ll also make smaller ‘mini-models’ to help sort out nested lists and whatnot.

Pierce » 5140 days ago #

I only do what feaverish is suggesting for big sites. Usually I can keep track cleanly enough by looking at the html.

The majority of my css is written sequentially, ie, rules for body, then rules for container, etc.

Commenting our code was hammered into us in college (not for html or css, but everything else we learned. the only html we were taught was frontpage). That might be the reason I hardly do it at all. I would more if I thought I was handing the code over to someone else at the end. I do name my classes and divs as clearly and cleanly as possible though.

I know how to be a better coder. I’m just a bit lazy. For personal projects anyway.

Rob Mientjes » 5139 days ago #

Jared, funny how we code pretty alike. When a rule has only one attribute (mostly * html …), I do the same thing. Indenting is a real help, and so is commenting. Luckily I know my own code, but do think of others if it’s a public project or a team effort. And I keep telling myself “Rob, you’ll forget what it’s about and screw up big time!”. Has worked every single time.

Justin » 5139 days ago #

Recently I’ve been putting all of my CSS properties on one line, no matter how long it gets. The compactness lets me see an entire stylesheet in a single screen, which is nice for quickly scanning what I have and how it all works.

With HTML I’ll indent it the way you mentioned, up until the main content of the page, which I’ll normally keep it completely unindented to make it easier to work with (especially when navigating using the arrow keys and Home/End).

Jeff Smith » 5138 days ago #

I try to use the tab hierarchy in the majority of my XHTML and HTML work. I think this is due in large part to my programming background.

The only time that I don’t use the tab hierarchy is when I’m dealing with CMS output, which at times, can get messy. I find the best way to deal with this situation is to left-justify all my code and separate it into blocks:

< div>
< p>Some output here...< /p>
< /div>

< div>
< p>Etc.< /p>
< /div>

This keeps things fairly clean and easy to manage.

Great article by the way Jared. Coding techniques are definitely something that kind of gets pushed to the side at times.

Feaverish » 5133 days ago #

Is it bad to post twice? No okay good. Another thing I do is leave a comment at the closing div, or li or whatever, saying which div I’m closing here. That way, if a page gets too long, I can see where things are opening and closing. I hope that makes sense.

« Older writing is available in the Archives.