View Single Post
  #8   Spotlight this post!  
Unread 29-04-2004, 10:46
Mark McLeod's Avatar
Mark McLeod Mark McLeod is offline
Just Itinerant
AKA: Hey dad...Father...MARK
FRC #0358 (Robotic Eagles)
Team Role: Engineer
 
Join Date: Mar 2003
Rookie Year: 2002
Location: Hauppauge, Long Island, NY
Posts: 8,820
Mark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond repute
Re: Coding / Style Standards for sharing C code

Here are some considerations for coding standards/styles from off the top of my head. I have opinions on all of these, but tried to eliminate them as I typed (I did let a few sneak by).

See if there are issues you can add to these. I'll edit this later to add definitions.


1) Use ANSI C standard

2) Design Considerations


a. Information hiding
b. Context based control
c. Object oriented programming
d. Modular solutions
e. Memory allocation

3) Error Handling


a. External status
b. Debugging tracebacks
c. Programmer debugging

4) Encapsulate or isolate CPU specific code dependence, e.g., PIC specific calls like timers, ADC. (we will upgrade to a new processor one day and it will be nice to easily take the existing repository code with us)

5) Avoid duplication of purpose



6) Miscellaneous
a. Use of defines, enum, etc. rather than embedded constants
b. No default Boolean tests
c. No syntax changes via macros
d. No nested macros
e. Avoid function like macros that do not behave like functions
f. No more than 80 characters per line
g. Standardize indents (I also much prefer spaces to TABs)

7) Naming conventions
a. Functions
b. Macros
c. Typedefs
d. Defines
e. Includes
f. Project Files

8) Documentation
a. Project file headers w/version, date, update history
b. Function headers
c. Non-function headers
d. Additional information blocks
e. In-line documentation
f. Manual pages


We’ll have to decide how to assign proper credit. We shouldn’t take up a lot of real estate with Team credits, but a single standard line would be nice. My guys like to put banners on that take up the whole screen. I hate that because it’s so much junk to skip over every time I need to look at a file.
__________________
"Rationality is our distinguishing characteristic - it's what sets us apart from the beasts." - Aristotle

Last edited by Mark McLeod : 29-04-2004 at 11:37.