Well John, I have been having a bit of trouble just from switching
between
C and ASM, as I don't use tabs at all in my C programming and I keep
tying
to comment with a ; or a // in the wrong places.
I like the indenting for the "conditionals"  I will try and incorperate
it
in my own style.  I guess from the lack of response on the topic of ASM
code
formatring, that thier is no standard or rule of thumb, just so long as
your
code works!
         Giles L. Honeycutt
         gilesami@ix.netcom.com


John Payson wrote:
> I've not decided whether I prefer my first tab stop at column 9 or 17, and
> my code unfortunately reflects this (if I import a piece of code from another
> app I've written, I'll often have to adjust it); the opcode field begins 8
> columns later, and the comments go in column 41 or 49.  One other thing I
> do, which I find helps code readability a LOT, is to indent by one space the
> opcode for any instruction which may be conditionally skipped:
>
>         movf    Foo,w
>         btfss   Z
>          clrf   Bar
>         iorwf   Bar,f
>         etc.
>
> When using double-conditionals [e.g. if I want Bar to be clear if bit Foo,0
> or Foo,1 is set]:
>
>         btfss   Foo,0
>          btfsc  Foo,1
>          clrf   Bar
>
> the indent is a little less than clear, but note that I do not add a second
> level of indent; if I did, it would appear that skipping the first instruct-
> ion would imply skipping the second when in fact the reverse is true.  Of
> course, some might argue against such constructs altogether, but I know of no
> other good way to, e.g., perform an add-with-carry that produces a meaningful
> carry out: