On Sat, 02 Jun 2007 10:01:06 +0200, neimad <[EMAIL PROTECTED]> wrote:
[...] I always put the comment on the line before the statement, so
I would write your example above as follows:
/* wait 200ms for the pull-up to rise before next standalone
* behavior otherwise position switches signals are wrong */
event_timer = 2;
Thanks, that's what I wanted to know, though I'm so used to it that I'll
have a hard time ... ;-)
What about defines, enums, etc., you'd put the comment/description of
define_1 on the right or on the line before?
enum my_enum {
define_1,
define_2,
}
There's the same for function calls, should we do
void my_long_function_call(parameter_1, parameter_2, parameter_3,
parameter_4)
or
void my_long_function_call(parameter_1, parameter_2, parameter_3,
parameter_4)
Both styles are ok and I have used both. Depends on the coding style
conventions. (For the second one, it is advised to indent the second
part with two indentation levels.)
I prefer the first one though, as I find it a bit cleaner (and it is
how Emacs indents C by default ;-)).
vi defaults to the second, I think we'll never agree on this ;-)
[...]
Hmm, ok then. If you have pointers on embedded-specific programming
practices, I'd be very interested (if only to avoid committing code
considered bad from an embedded pov).
Looking into this again (to find you some pointers), I'm not sure my
previous statement was right, I'll have to do some tests again. This was
discussed on the avrlibc mailing list some time ago. But what I'm sure now
is that a swicth can be very efficient if all cases are incremental as it
can use a lookup table, otherwise it generates a if-then-else sequence
which takes much more space. In i2c.c (tuxcore) I created the lookup table
manually as the compiler never wanted to do it, and I saved more than 100
bytes doing so.
I'll let you know if I find something interesting.
In commit r335:
typedef enum
{
USB_CONNECTION_CONNECT = 1,
USB_CONNECTION_DISCONNECT = 2,
USB_CONNECTION_ID_LOOKUP = 3,
USB_CONNECTION_CHANGE_ID = 4,
USB_CONNECTION_WAKEUP = 5,
USB_CONNECTION_WIRELESS_CHANNEL = 6,
} USB_ID_PARAM1;
The type is badly named: "USB_ID_PARAM1" is about its *use* whereas
its name should really be about what it *is*.
Well, it *is* the first parameter of the USB ID command which I later
renamed USB connection command and probably forgot about it here.
Thus I would rather have the following:
typedef enum
{
USB_CONNECTION_CONNECT = 1,
USB_CONNECTION_DISCONNECT = 2,
USB_CONNECTION_ID_LOOKUP = 3,
USB_CONNECTION_CHANGE_ID = 4,
USB_CONNECTION_WAKEUP = 5,
USB_CONNECTION_WIRELESS_CHANNEL = 6,
} usb_connection_t;
The type is in lower case suffixed instead of all-uppercase, it is
suffixed with _t (a widespread convention) and it is consistent with
its values: usb_connection_t / USB_CONNECTION_xxx
Yep, my fault, I was probably asleep at the time I wrote that. I'll fix
it, write it 100 times and go to sleep without eating ;-)
Thanks,
David
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
tux-droid-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tux-droid-user
