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

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

RE: [avr-libc-dev] Adding (some) Procyon AVRlib functionalityto avr-libc


From: Weddington, Eric
Subject: RE: [avr-libc-dev] Adding (some) Procyon AVRlib functionalityto avr-libc
Date: Fri, 18 Sep 2009 13:30:51 -0600

 

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Ron Kreymborg
> Sent: Friday, September 18, 2009 6:22 AM
> To: address@hidden
> Subject: RE: [avr-libc-dev] Adding (some) Procyon AVRlib 
> functionalityto avr-libc
> 
> 
> 1b. All public functions are lower case using underscores for 
> readability
> with up to 4 letters defining the device.

I prefer 1b, though without the 4 letter restriction (think: "spi"). I prefer 
not to abbreviate unless absolutely necessary.

 
> An example of 1a) would be spiSendMessage, and of 1b) 
> spi_send_message. I
> vote for 1a but democracy would rule.

So I would prefer the example "spi_send_message", though I would personally 
reduce that to "spi_send" as one is sending generic data, not any predetermined 
"message" format.

> 2. All modules which require prior initialisation use the 
> same name for this
> function, such as Init or Setup. Eg spiInit or spi_init.

Agreed. Most would require initialization, so "spi_init".

 
> 3. All internal data structures are private (static) and only 
> accessible via
> public functions. All internal functions are likewise private.
> 

Agreed.

BTW, I too like the API naming style of <object>_<action>, such as "spi_init", 
"spi_send", "uart_receive", "adc_read", etc.

> --------------
> 
> If this looks like the definition for a C++ class then that 
> is my basic
> idea. 

Though, at this point, I would want to stick to writing this in C. But I won't 
rule out actually using C++ sometime in the future.

 




reply via email to

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