[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.
- RE: [avr-libc-dev] Adding (some) Procyon AVRlibfunctionalitytoavr-libc, (continued)
- RE: [avr-libc-dev] Adding (some) Procyon AVRlibfunctionalitytoavr-libc, Weddington, Eric, 2009/09/19
- Re: [avr-libc-dev] Adding (some) Procyon AVRlibfunctionalitytoavr-libc, Mike Perks, 2009/09/19
- RE: [avr-libc-dev] Adding (some) Procyon AVRlibfunctionalitytoavr-libc, Weddington, Eric, 2009/09/19
- Re: [avr-libc-dev] Adding (some) Procyon AVRlibfunctionalitytoavr-libc, Mike Perks, 2009/09/19
- Re: [avr-libc-dev] Adding (some) Procyon AVRlibfunctionalitytoavr-libc, Ruud Vlaming, 2009/09/20
- Re: [avr-libc-dev] Adding (some) Procyon AVRlibfunctionalitytoavr-libc, Ruud Vlaming, 2009/09/19
- Re: [avr-libc-dev] Adding (some) Procyon AVRlibfunctionalitytoavr-libc, Frédéric Nadeau, 2009/09/19
- RE: [avr-libc-dev] Adding (some) Procyon AVRlibfunctionalitytoavr-libc, Ron Kreymborg, 2009/09/19
- RE: [avr-libc-dev] Adding (some) Procyon AVRlibfunctionalitytoavr-libc, Weddington, Eric, 2009/09/18
- Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc, Joerg Wunsch, 2009/09/18
- RE: [avr-libc-dev] Adding (some) Procyon AVRlib functionalityto avr-libc,
Weddington, Eric <=
- RE: [avr-libc-dev] Adding (some) Procyon AVRlib functionality toavr-libc, Weddington, Eric, 2009/09/18
- [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality toavr-libc, David Brown, 2009/09/20
- RE: [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionalitytoavr-libc, Weddington, Eric, 2009/09/20
- Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc, Joerg Wunsch, 2009/09/18
- RE: [avr-libc-dev] Adding (some) Procyon AVRlib functionality toavr-libc, Weddington, Eric, 2009/09/18
- [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality to avr-libc, David Brown, 2009/09/20
- RE: [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality toavr-libc, Weddington, Eric, 2009/09/20
- Re: [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality toavr-libc, Jan Waclawek, 2009/09/20
- RE: [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality toavr-libc, Weddington, Eric, 2009/09/20
- Re: [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality toavr-libc, Jan Waclawek, 2009/09/20