programming best practices?

hi all, wrote my first arduino program woot! woot! fun stuff!

is there a best practices doc here or somewhere on the web? or will i have to go through each forum post here? ;-) thanks!

There are tons of books on best practices. My standard recommendation is "Code Complete" by Steve McConnel.

Anyway I find it more convenient to go for books instead of browsing the web. If prefer browsing the web you might start here:

""Safer C" by Les Hatton.

thanks for your responses.

i guess my question was a little vague and i apologize for this.

i am like most coders out there i guess - as long as it runs without exceptions, can be easily understood and modified when i look at it again (3 mos from now) = it's all good. optimization is one of the last i take into consideration. readability and self documentation is more important to me. with the arduino however, i guess this is something that i need to watch as my heap is a little limited.

i was really looking for more information when programming autonomous behavior. for example, is excessive use of flags a norm when programming with stuff like sensors, and all diff kinds of actuators? what sort of techniques allow simultaneous monitoring of multiple sensors, etc.?

i rarely get books now. they're expensive!!! $40, $50? sometimes used $4-$7 from amazon works but still. and more often that not, i just needed to look at a chapter or two. i feel bad looking at all these books i purchased over the years that went obsolete after a year or less even. i'm sorry but i'm one of those who now treat barnes&noble as a library. :-)

You can buy used books and you can sell books you do not need anymore. But if you do not read, where do you want to learn? The internet is not always the best source of information.

Looking at your code you will benefit from one of the books that teach C style. I still read books and I do so for >20 years. Yes they are expensive but what do you expect for free? If you do not want to read books: go and find someone more experienced and try to get first hand advice.

is excessive use of flags a norm when programming with stuff like sensors, and all diff kinds of actuators?

For simple State Machines, yes.

what sort of techniques allow simultaneous monitoring of multiple sensors, etc.?

State Machine.

My favourite is the Quantum Framework published in Dr. Miro Samek's book. You can find more information here... His ideas and code saved my butt on a CANBUS project I did last year. Unfortunately, I have not found a port that would work well on the Arduino and I haven't had time to do it myself.

AlphaBeta has kindly published this...

This is a good starting point for general information...

Are you asking for a critique of your code? Here are a couple things that stood out, at sort of the "bottom" (programming) level:

1) Since you have light states, it might have been nice to #define constants "ON" and "OFF" instead of continuing to use HIGH and LOW.

2) You carefully #define constants for INT_foo, but there are other "magic" numbers (4000, 5000, 150) in the code proper that should probably also be #define'd...

3) Needs more comments and better function names ("trafficLights1" ?! What does it do ?)

Up a level, more in the "design" phase, I think I would have preferred to see a more state-oriented approach, rather than manipulation of the individual "lamps" in each traffic light. But I'm not sure whether I would have done a per-light state (RED, YELLOW, GREEN) or a per-intersection state (WEST_GO, WEST_WARN, EAST_GO, etc...)

Overall, pretty good !

I'd say that the most important "Programming best practice" is the one you're doing. Always be looking for ways to make your code clearer. Faster and smaller come later, when the intent is as clear as possible.

these are all awesome comments. 8-) ... pauls, totally agree. that is why they invented versions.

i think i got my answer. need to read more on "state-oriented" coding. need to read more on "state machines". i live and breathe this everyday - more on the database side though, pl/sql, etc. - and it's different in a way.

westfw, thank you for the critique. dude, i'd stay away from you if you do source code audits where i work. ;D ...

If I would be working at westfw's place I would try to get my code audited by him. Do not try to run away from people showing you how to get it done better ;) If you have to run from code reviews, then your management makes a big mistake --> then maybe you should find a different place to work.

I would try to get my code audited by him.

Thanks. You have the right attitude. However, I'm actually not a very good code reviewer. I tend to notice things like "gee, you ought to have a #define for that purple traffic light color", and miss that traffic lights ought not be purple...

Still, the best code reviews are arguments/discussions, rather than simple "change this"/"yes sir" interactions. As long as neither side has too much emotional investment. We could argue for weeks on whether there should be "intersection state" or "light state", while XYZ TrafficLights Online gets to market first and steals all our customers!

westfw, i meant that as a compliment, just in case you didn't get it. ;-)

yes. i've been in a lot of arguments, heated discussions even, with qa and validation "specialists" arguing irrelevant issues that will always end up with a ton of additional paperwork, hence delays.

udo, you have great work ethic and if you like this kind of environment, more power to you.