|
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) Miscellaneousa. 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 conventionsa. Functions
b. Macros
c. Typedefs
d. Defines
e. Includes
f. Project Files
8) Documentationa. 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.
|