Menu Home

Code Properly Damnit

Some hints for budding webdevs:

CODE PROPERLY DAMNIT.

Look, we all know web languages are often looked down upon by programmers (some of the higher level ones such as php or asp are often ‘acceptable’) but that is absolutely NO reason for good coding practices to not apply to web code. So here’s some pointers:

1) Make it standards compliant
A lot of people coding just hack away and think “to hell with people who use mozilla/netscape/opera/etc, most people use IE so I’ll code for them”
WRONG!
Why code for a select few when you can code for everyone? There’s not much you can achieve for a particular browser that you can’t achieve using an alternative standards based method that will in turn work for all browsers. If you dont know, ask (not me, coding forums.) Coding to standards is also important for accessibility.

2) Code for other coders, including yourself (eg Make it readable)
If there’s one thing I hate about reviewing other people’s code, it’s trying to decipher what the hell they were thinking when they coded, and trying to read through it to make some sense of how the browser is going to structurally render the page.

Let’s say you get an error with your code. You pop into your source and think “what the hell was I doing? ummm where is this problem?” With well structured code you can just skim through it in chunks, locate your problem and bang.. problem solved. Quick, easy, painless. Your blood pressure remains the same. I call this mentality “A small job now saves a huge job later.” Remember that, it might help you out in life.

So spread your code out. SPREAD IT OUT, LIKE MARGARINE.
If you spread it out it seperates it into digestable chunks. Easy peasy to review and fix errors.
Comment your code. COMMENT IT, LIKE DR SEUSS.
If you comment your code, someone reviewing it later on can see what it is you were attempting to do, and how you were going about it. They can then follow your train of thought and see where you may or may not have gone wrong.

Bad:

<html><head><title>WELCUM 2 MY PAEG!</title></head>
<body font=wopbopaloobop size=093402934 color=black (like Mr T)><table>
<tr><tab bet_on_horse_3="true" /><td>some content here</td></tr><table name=forthehellofit><tr>
<td>some more embedded content</td></tr></table>
</table></body></html>

Good:

<html>
<!-- Head Section -->
<head>
<title>Hello World!</title>
</head>
<!-- /Head Section -->
<!-- Main Content Section -->
<body>
<!-- Main Table.  This will hold subtables -->
*table code here*
<!-- Subtable -->
 *subtable code here*
<!-- /Subtable -->
*closing table code here*
<!-- /Main Table -->
<!-- /Main Content Section -->
</body>
</html>

Obviously I’m not going to do a full bag of code because it’ll just take up a whole whack of space, but you can see in the second example the code has structure and commenting, and is subsequently a lot easier to read.

3) Seperate formatting from content (eg Use Cascading Style Sheets)
I know a lot of you think it’s great and easy to just use that horrible font tag, and I admit that if I’m throwing together a one page site, I’ll use the font tag because it’s quick and easy. HOWEVER when your site gets big, what happens when you want to change the theme? You have to go through multiple pages and manually edit the code. What a hassle! Not to mention with all the formatting code messing up your overall source, it increases overhead and makes your code a bit more complex and difficult to read.

So USE CSS. CSS is a godsend. Imagine, one file that controls your entire theme. You want to change your hyperlink colour from blue to grey? Just change one line in your CSS file, not hundreds of lines of code throughout your site. And if you want to override it? No problem, just override it where you need to. It will cascade back and voila, you have yourself an easily formatted and consistent site. Saves a lot of headaches, trust me.

4) Code for all possible monitor resolutions
If you’re coding to standards you should be putting in width and height parameters. Now if we all used one monitor resolution things would be dandy, but we dont. So pick a bottomline resolution (usually 800×600 but increasingly 1024×768 ) and code primarily for that. Then instead of using pixel parameters, put in percentage parameters whenever you can. This applies to items that take up a percentage of the screen.. say you have a banner image across the top of your site and a table that helps with your layout:

BAD:

width="1024"

GOOD:

width="100%"

With percentage measurements, your items will scale to a percentage of the browser window. Let’s say you have a banner that’s 1024pixels wide. Use pixel width and users of 640×480 and 800×600 will get horrible horizontal scrolling in their browser windows (if you dont define pixel width it’ll default to the maximum width of the image anyway). Use percentage and the image will scale down to only the width of the browser. Well fancy that.. with one simple change in code you’ve just catered for a wider audience. Logical huh?

Check out some of the code used on this site.. it’s not always up to my high standard because this blogging software is database driven, so I didnt want to mess with the code too much, but it’s certainly FAR more decipherable than most sites out there 🙂

Learn to use reliable resources from around the internet. w3schools is a good starting point.

Good luck, young webdevs.

Categories: Write Ups

rawiri