> ALL_CAPS is used for defines, EQU, macros, and constants > First_cap is used for function names, something with a return at the > end > all_lower is for simple labels for close by GOTOs in side of > functions. > Underscore_at_end_ is for any function in PAGE1 rather than PAGE0. I > have not had to use a larger chip, so I don't have > anything for PAGE2 or PAGE3. > underscore_at_end as above, but not a function call, just for GOTOs. > ;label_comment I do this when a branch falls through and a labels I personally prefer caps for code labels and MChip-defined I/O designators (e.g. PORTA); FirstCase for most data labels, _LEADING_UNDERSCORE for code branch tables, and for other bizarre constructs, whatever I come up with... 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: movf Source,w btfsc C incfsz Source,w addwf Dest,f [does anyone know who invented that ingenious piece of code? They should win an award or something...]