Nic,

I agree with most of what has already been said. I believe you have to compose your source with the assumption someone else will be tasked to perform follow on work.

code in lower case, expresive labels (and i don't mind24 character names if they tell something useful i.e. DAC_output_buffer_index).

Andy is correct about the Tabs vs. Spaces (and there impact upon editors) but i like the space efficiency of Tabs so i use them and am willing to "set tabs" as most decent editors allow.

With 8051 assembly i use Upper Case for SFR's and Hex encoding (i.e. "mov PCON,#080H")

I comment like crazy generating that "book" that was previously indicated as tedious for some. If find it has saved my life when i have had to revisit 10 year old code.

I use "banner" comments above routines to explain the goal in plain english (if you "strip" these banner comments into another file you have a great start on a "theory of ops" doc).

I use the comments on the right to explain the platform "mechanics" of what is happening. I dislike comments that repeat what an opcode already says i.e.

mov a,#0A0H ; move to the accumulator the hex value 0A0H
.

Also i generate a lot of "white space" to partition related and un-related code.

I prefer to avoid source files that combine unrelated functions and use "lib" and "inc" files so that individual source files contain the data, constants, sub-routines and top-level processing associated with each major architectural sub-division of overall processing.

regards,
p