> (C programming guidelines)
> For the others i'm not sure which one to select and follow.

As often, there is no subsitute for your own good judgement. A guideline
aimed at mainframe batch data processing might not be a good choice for
embedded real-time programming on <1k code microcontrollers. A guideline
for a company that prefers to employ freshmen from college will
emphasise quite different aspects than one that relies on 20y+
experience C gurus.

Having said that, there are a few things that are IMHO more important
than which guideline you choose:
- do choose one, any guideline is probably better than none
- if it is a guideline, I assume you will (maybe midly) enforce it, so
there will be a (maybe small) penalty for not following it. If this is
the case, you will have to install an exception mechanism. It can be
anything from a blanket statement in the project file, up to a formal
request/grant cycle for each individual deviation.
- a guideline should be a living document, or it will die. do update
your guideline based on the experience in your context.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
 


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist