Here is your one stop for learning how to properly format your work. But beyond that, I am also aiming this article at good coding practice in general. You may not think much of it now, but good, clean coding and formatting practices do, in fact, lead to less or easier-to-spot bugs in your code. If you have a method that isn't too similar to the ones that follow, feel free to tell me about it so the rest of the world can benefit!

First off, you always want to finish things before you start them. What do I mean? I mean that if the block of code you are starting has an ending that is largely similar every time you use it, then type out that ending right after you type out it's beginning. C++ has many examples of this. Functions, loops, if statements, structs, classes, while and do-while. All of them have that closing bracket, and some have an additional few characters after it. When you're writing any of these, go ahead and type the closing bracket after you write the opening one. The layout of the standard keyboard is designed to make that motion quick and easy.

In C++, there's a quick series of keystrokes that I do whenever I use one of the aforementioned blocks of code. In a compiler that sets the margin for the next line to the beginning of the text on the current line this is especially easy. Simply type the command (if, for(whatever), function(), etc), press enter, enter the two brackets ({}), press left, enter twice, up, and double space. That results in the block being ready to fill, and it's an extremely quick motion once you get the hang of it. On notepad, however, you have to modify it slightly with a few taps of the spacebar to get everything looking right.

In addition to that, I've also found it advantageous to separate dissimilar blocks of code with an extra line break. Say I declare a group of variables. I take special care to keep all of the data types together, and then I simply put a double line break to set those declarations apart from the rest of the code. In a program with many functions in it, you may also strongly consider putting a commented line (//--------------) between each function. This makes it much easier to find the function your looking for.

In HTML, things get a little more difficult. Many tags in HTML don't require closing tags. Here, consistancy is key. Either do it all the time or don't do it at all unless it's required. And like C++, write the closing tag at the same time you write the opening tag. I can't count the number of times I've poured over a page of HTML that I've written looking for an error, only to find that it was a missing (or even extra) closing tag. Writing your closing tag at the same time as your opening tag is a good way to pretty much eliminate that annoying little error.

But by far the most important practice in HTML is formatting your code. With tables, put each tag on a line of it's own, and indent them properly, as shown in the table lesson of the HTML tutorial. This leads to much easier error correction - and you will make plenty of errors when working with tables until you get very skilled at it. And even when you are skilled, when good formatting isn't employed changes are extremely difficult. For your own sake, take my word for it. I myself am very guilty of using bad formatting, and I have paid with hours of my time for it.

Want to see how much of a difference good formatting makes? You asked for it! I'll just pull the code from a moderately complex table I used in that table lesson... 

<table border=1 width="180px" height="180px" align=center>
<tr>
<td align=center valign="middle">
R1C1
<td align=center valign="bottom">
R1C2
<td align=bottom valign="top">
R1C3
<tr>
<td align=right valign=bottom>
R2C1
<td rowspan=2 colspan=2 align=center valign=top>
R2C2
<tr>
<td valign=top>
R3C1
</table>

This isn't too bad, but it still takes a comparatively long time to figure out it. Figure out what it's doing and then scroll down to the same block of code with nothing more than proper indentations. 













<table border=1 width="180px" height="180px" align=center>
  <tr>
    <td align=center valign="middle">
      R1C1
    <td align=center valign="bottom">
      R1C2
    <td align=bottom valign="top">
      R1C3
  <tr>
    <td align=right valign=bottom>
      R2C1
    <td rowspan=2 colspan=2 align=center valign=top>
      R2C2
  <tr>
    <td valign=top>
      R3C1
</table>

As you can see, it's much easier to interpret a block of code that has something as simple as proper indentation. Look at that same table with fairly bad formatting... 

<table border=1 width="180px" height="180px" align=center>
<tr><td align=center valign="middle">R1C1
<td align=center valign="bottom">R1C2
<td align=bottom valign="top">R1C3
<tr><td align=right valign=bottom>R2C1
<td rowspan=2 colspan=2 align=center valign=top>R2C2
<tr><td valign=top>R3C1
</table>

This is how I sometimes write my code when I'm extremely impatient. And more often than not I have to spend that much extra time finding the > sign I left out or finding the quote that got away.

Aside from just looking better, properly formatted code typically has a lot of white space. And in coding, you'll quickly find that whitespace is your friend. The less your eye has to sift through on each line, the closer it can concentrate on the specific operations and syntax of that line, and the quicker it discovers that misplaced quote or < sign.