some recent postings have made me think about posting the below, so here we go.

I am a great proponent of defensive coding, how?
1) there is no reason whatsoever to try to be "elegant".
2) if it does not look good in the debugger, rewrite it.
3) if you use "free code" load it in the debugger, work a bit with it, then throw it away. If you got an idea or two, great.
4) long ISRs are outlawed.
5) anything timing dependent that is not interrupt based is outlawed.
6) only the small memory model is legal.

I am a great proponent of defensive coding, why the above points?
1) "elegant" code is 10 times more buggy and 10 times more difficult to debug.
2) writing code is easy, reading code should be that too.
3) if you can not make "free code" lokk like yours it is more dangerous than helpful.
4) while such are possible OK they should only be resorted to after much research showing that no other method exist.
5) I have not had a need to break this rule, but otherwise see 4)
6) the large/huge etc model is very convenient, but "remembering" to make critical variable "data" is so much more error prone than to have to make some large arrays and buffers "xdata".

None of the above preclude well worked out code that is "right", sometimes it is, indeed, more demanding to write "defensive" code than "elegant" code. I think that it requires more skill to write "dull, working code" that "really smart code with only a few bugs".

The above does, indeed make the coding more dull, but as someone once said "they call it work, that is why they pay you for it".

Now, it is, of course, fun now and then to do some really fancy code, that's fine, just do not let the people that pay you suffer for that reason.

Erik

Ok, start arguing, I'll sit back and smile