[Olsr-dev] questions regarding v2 coding style / lang

[Harald Geyer]

> If we can't use C++ and boost etc. in order to keep things nice, we  
> will need a better coding style for v2.
> Any suggestions regarding this?
> 
> What works best for you for small embedded devices while keeping  
> things very portable and small and readable?

It might seem strange to mention this on a question about portability,
but it think the linux kernel coding style has some good points:

/usr/src/linux/Documentation/CodingStyle

A few other ideas - perhaps obvious anyway:

Use of big endian names and parameter ordering for (global) variables
and functions. I.e. something like links_symm_count() instead of
little endien count_symm_links() or even worse middle endien
symm_links_count().

Having more modular code would make it easier to write things like
slave olsrd (as discussed with henning last month) and debugging tools.
Having the directory hierarchy resemble this would make it easier
to get familiar with the code.

I think avoiding gnu autotools in v1 was a good idea and should be 
continued in v2 ... some minor code duplication between supported
systems is ok if it helps speed up things or allows cool features that
otherwise would be quite complex.

Fail save but don't annoy: In a mesh it is typically a good idea to
not start the routing deamon if we fail to load the configuration
properly. Losing one node doesn't hurt but having one node running
amok does. OTOH it is annoying if olsrd doesn't come up because it
doesn't find txtinfo plugin or something similiar - might be that
you just lost the only route to fix the problem and now need to
drive through the entire city to get physical access to the node ...

HTH
LFTWSC

Harald