As for comments, there's good and bad ways of doing it.
For instance:
BAD:
// Set digital pin 4 high
DigitalWrite(4, HIGH);
That's a useless comment. Anyone with a basic understanding of the Arduino environment already knows what DigitalWrite does. But WHY are you setting pin 4 high?
BETTER:
// De-select the SD card module
DigitalWrite(4, HIGH);
Even better, however, would be to make the code itself clearer and explain why you want to deselect the SD card:
A BIT BETTER:
#define SDCARD_SELECT 4
...
// We de-assert the SD card to avoid SPI bus contention while we use
// the ethernet chip
DigitalWrite(SDCARD_SELECT, HIGH);
Basically, when writing comments, assume that the reader has basic knowledge of the environment. So explain things that are tricky, but don't explain things that are obvious. And, if you can make them obvious in the first place so they don't need a comment, even better. Not every line of code needs a comment (although most programmers write too few, not too many).
I also typically comment any math I do - not something like:
// We divide by two to get distance
distance = sensorReading / 2;
After all, anyone can see that divides by 2. The question people have is "WHY?" (you'll have it in 6 months, too, even if it is your code).
So, something like:
// Distance from this sensor is 1/512 of Vcc per inch, so it's exactly 1/2 of
// the AnalogRead() reading
distance = sensorReading / 2;
Some other tips - use subroutines:
If you find yourself indenting more than 3 or 4 levels deep, you probably need to call a subroutine to make it clearer.
If your subroutine doesn't easily fit on your screen, you probably need to break it into smaller subroutines.
If you are repeating code, maybe only with a tiny change, you probably need subroutines.
Of course there are exceptions to all of these rules (speed is not one, BTW; you can use the "inline" directive when creating a subroutine, which will tell the compiler to "unroll" the subroutine and put it directly in each location of code that calls it - to increase speed). But generally you start with it broken down if at all possible.
Finally, if I'm modifying someone else's code, I try to follow their style, not impose my own (so if they use 8 character indents, so do I, for instance). Other than that, I try to follow the style/formatting I see most often in that environment - that means it's easier to get help if I need it!