Tuesday (08/22/06)
Making Code Poetry Part II: Visual Form 3:18 pm
Visual form within code is important when it comes to readability, usability, accessibility, and all those other “bility”s. Many of the W3C’s standards give some visual form guidelines to follow, and there are many more besides these which can help in development.
Beginning What You Started & Pulling Things Together
Much like some poetry uses rhyme to pull together ideas and complete thoughts, the W3C has told us to always close all tags in XHTML (excluding the doctype).
When we don’t close our tags, code is really hard to track and debug. Take a look at this:
<div><ul><li><img src="image.gif"><li><p>test<p>some more text</ul></div>
I closed a few tags because without closing the div and ul things probably wouldn’t even work, though in HTML closing li and p tags are not required. Still, looking at that gives me a headache.
If we close all our tags (by XHTML standards), take a look at how much easier it is to read:
<div><ul><li><img src="image.gif" /></li><li><p>test</p><p>more text</p></li></ul></div>
That allows us to see exactly where things start and where they stop.
Line Breaks
Line breaks are important tools for poets. Can you imagine reading some poem that’s all on one line? Crazy. Same with the code I just showed you above. Look what our code can become with the help of a few linebreaks:
<div>
<ul>
<li><img src="image.gif" /></li>
<li><p>test</p><p>more text</p></li>
</ul>
</div>
By grouping code by tags and content, it makes it that much easier to follow.
Spacing
Appropriate tabbing and spacing can make all the difference in the world. Lets take our last version of code and add some spacing in it to see what we can do:
<div>
<ul>
<li><img src="image.gif" /></li>
<li><p>test</p><p>more text</p></li>
</ul>
</div>
By spacing things accordingly, we can actually see where our elements begin and end just by scanning vertically. This gets even more convenient when using a good code editor such as Notepad++, which has built-in indent guides.
Lets compare this to our first version of code:
<div><ul><li><img src="image.gif"><li><p>test<p>some more text</ul></div>
Which would you rather work with?
Now obviously, these examples used a very simple bit of code. When developing some advanced JavaScript, using visual form guidelines such as these can make an even greater impact on the aesthetic qualities of your code. As Snook mentioned in his Rapid DOM Development session, being consistent in your coding style really speeds things up. Examples he gave for JavaScript include using camelCase, uppercase for classes, and all caps for constants.
Some More Advanced Code
Incase you still don’t believe me, I’ll give you an example of some more advanced JavaSript.
Take a look at this mess:
var live = { // ......
close: function() { Effect.SwitchOff('searchresults', {queue: {position: 'end', scope: 'close'}});
Effect.Fade('closeresults', {duration: .5, queue: {position: 'front', scope: 'close'}});
}, Active :function() { if(this.Browser == true) {
var indicator = document.createElement('img'); indicator.src = 'indicator.gif';
indicator.id = 'indicator-safari';
indicator.style.display = 'none'; $('search').appendChild(indicator);
Effect.Appear('indicator', {duration: .5, queue: {position: 'end', scope: 'active'}}); }
else { var indicator = document.createElement('img'); indicator.src = 'indicator.gif';
indicator.id = 'indicator';
indicator.style.display = 'none'; $('search').appendChild(indicator); Effect.Fade('searchsubmit',
{duration: .5, queue: {position:'front', scope: 'active'}}); Effect.Appear('indicator', {duration: .5, queue: {position: 'end', scope: 'active'}});}}, // ......
}
And look at what it could be:
var Live = {
// ......
Close : function() {
Effect.SwitchOff('searchresults', {queue: {position: 'end', scope: 'close'}});
Effect.Fade('closeresults', {duration: .5, queue: {position: 'front', scope: 'close'}});
},
Active : function() {
if(this.Browser == true) {
var indicator = document.createElement('img');
indicator.src = 'indicator.gif';
indicator.id = 'indicator-safari';
indicator.style.display = 'none';
$('search').appendChild(indicator);
Effect.Appear('indicator', {duration: .5, queue: {position: 'end', scope: 'active'}});
}
else {
var indicator = document.createElement('img');
indicator.src = 'indicator.gif';
indicator.id = 'indicator';
indicator.style.display = 'none';
$('search').appendChild(indicator);
Effect.Fade('searchsubmit', {duration: .5, queue: {position:'front', scope: 'active'}});
Effect.Appear('indicator', {duration: .5, queue: {position: 'end', scope: 'active'}});
}
},
// ......
}
I find the last bit actually enjoyable to look through.
So stick with (most of) the standards, develop your own coding style, and work towards turning your code into a nicely formed bit of poetry. 
(Stay tuned for Part III which will focus on resourceful and condense coding. If you haven’t read Part I yet, you can catch it here: Making Code Poetry Part I)
I eat food. I listen to music. I sleep. Sometimes. I drink lots of coffee. I make pretty pictures. I talk to people. I believe in things. I write stuff. I take photographs. I have a laughing addiction. I am human. 
As a new computer engineer intensely studying programming, let me point out that it is now an industry standard. For C++ or Java classes, if you don’t format your code above, you will lose 20% for your points for that homework or project. And let me also point out that comments are required. The courses encourage open source with strict requirements for letting the next person know what is going on including a readme.txt.
@James: That’s good to hear. Nice to know that there are places actually teaching good coding habits. Unfortunately, however, it’s not everywhere.
Sort of along the same lines as what Jeremy said…one of the most important things drilled into me by my teachers during school from the beginning is the importance of readable code.
I think the lack of readable code is more-so an issue for those who are self-taught or are accustomed to being the only developer on a project. This is a great series of articles, keep up the good work.
Something that might be worth mentioning in part 3 is the importance of white-space (not just limited to indenting). Logical blocks of code should be grouped together appropriately with white space (i.e. a blank line) separating them. This makes it easier to jump around the code. Falling in line with the “making code poetry” analogy, this could be seen as verses of a poem.
Of course, there are languages that require you to have indented and spaced code, such as python. And python has the side effect of being very readable, so that most of the time you don’t need an awful lot of comments.
@Matt: Huh, I didn’t know Python was like that. I should play around with it sometime.
And for the rest of you who are waiting for Part III…Don’t worry, it’ll be done sometime. It’s mostly written, but not quite finished yet.
[…] If you missed Parts I and II, you can read them here: Making Code Poetry Part I (an introduction to poetry) and Making Code Poetry Part II: Visual Form […]
wagonette medina plurative trippingly forestiera sourcefulness knotberry wiresmith
Clinton asks to quit Supreme Court Bar
http://www.sfonditalia.it/Favole.htm