avr-libc-corelib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Avr-libc-corelib] proposed corelib style guide


From: Ron Kreymborg
Subject: [Avr-libc-corelib] proposed corelib style guide
Date: Wed, 23 Sep 2009 16:25:06 +1000

A few points of difference:

FUNCTIONS
I have mentioned elsewhere that corelib can use both camels and underscores
with little effort. There are enough of us who use the former and abhor the
latter that I for one am prepared to include both so I can eventually use
the library without grinding my teeth at every function.

VARIABLES 
Let's not prepend or append private functions with anything. Making them
static hides them away from other modules. We can't say at this time that we
will never have a global variable, and I agree including one will need a
strong argument. However at this stage the ones I can think of can be
covered by call-backs, eg 

void GetClockFrequency(long crystal);

Thinking of call-back, is there some gcc modifier that allows for definition
of a "weak" function? This would allow call-backs to be instanced in the
library as null functions and save the user from creating an instance in
their code just to satisfy the linker when they have no need for it. Hmmm.
Or does that invite problems?

CONSTANTS
I am ambivalent about always pre-pending the module name to constants.
Perhaps for defines within the code (and thus private) needs not, but it may
be a requirement for public module constants as similar names will probably
come up as the library develops.

DATA STRUCTURES
Oh dear. It's a pity we didn't all go to the same School for Programmers. I
name a type definition in upper case and instances in camel (where did this
"camel" come from?). However I agree exposed typedefs should conform to a
style. Please let's not add stuff like _t to names - what's the point?

Ron








reply via email to

[Prev in Thread] Current Thread [Next in Thread]