James,

Thanks a lot! This is the kind of advice I was after :)

At 11:05 18/06/2002 -0700, James Newton. Admin 3 wrote:
>The wonderful thing about standards is that there are so many to choose
>from... <GRIN>

:))

>I personally try to use all lower case for keywords, Underscores in
>variables, All uppercase for defines or constants.
>
>Type of variable as first part of variable name, Since labels are variable
>of type "address" I try to use "at" or "a" as the first letter of labels,
>but they also denote the start of functions or procedures so sometimes I use
>"f" or "p" or even "s" or "sub."

At the end I think I'm going to adopt the following:

- only tabs, no spaces. 4-spaces per indentation level.

- one-character extra indentation for "bit-skip"-like operations.

- C-style all-lowercase names for variables, with underscores separating
   words:

   timestamp
   sigA_count
   sigA_time
   adc_ch1
   adc_ch2
   ...

- Same for 'higher-level' labels (i.e. function names or entry points
   for high-level blocks)

- Preceding underscore helps distinguish local labels within a function
   or block:

   _skip_hi
         [...]
   _skip_lo
         [...]

- All uppercase for constants:

   SPI_PACKET_LEN
   PROTOCOL_ID
   PROTOCOL_VERSION

- And of course all uppercase for PIC registers.


>Actually, when I'm writing code for someone else, I try to find out what
>language standards they follow. If the boss knows asm I try to get a look at
>his code, If he or she knows Pascal I use that style, if it's BASIC
>(shudder) I use that style. I even define macros to make some of the more
>obvious commands match the "language" I'm trying to look like. Macros are
>great for making code easy to understand.... if the macros make sense.
>
>And as Olin will probably say, comments are the best coding style. I don't
>comment every single line, but I write the program in pseudo code comments
>first and then "compile" each comment line into the ASM code that does what
>the comment says. No more than a few lines of ASM per line of comments. The
>tricky part is not changing the ASM code without updating the comments. I
>also keep a log of the design decisions at the start of the file with the
>date and what we were thinking at that point.


Very good advice, thanks!

G.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.