This is what you get when you throw a windows app programmer at embedded programming.

Well, we've seen worse ;), like trying to make the poor '51 wrestle with dynamic memory allocation or function pointers. Or people complaining that their C compiler doesn't understand C++. Or people wondering why their program will break any timing constraints when they're trying to do heavy floating-point math inside an ISR.

Many of Russ' tips are not specific to embedded programming, though. Using constants or #define's instead of magic numbers applies pretty much everywhere. The same goes for avoiding global variables unless there are very specific reasons for using them ("programmer convenience" doesn't count here).

As Russ said, interrupt service routines should be kept as short as possible, and preferably not call any other functions, since you will have to deal with reentrancy issues in that case. Anything you do in an ISR will have to be checked for common problems that arise in multitasked- and real-time systems (race conditions, reentrancy issues, atomicity issues, etc), which adds another boatload of possible problems to the number that can pop up in a non-multitasked program.