This is C89 style code where you couldn't declare the loop variables in the for loop, as in "for (OBJECT * obj = ... ". There's no problem with this code. The obj variable is initialized in the forEachObject macro which expands to a for loop. (Pretty damn sure - I haven't actually looked up the definition).
The array iteration code is also solid. Seems like a pretty good programmer, judging from the code you cite here at least.
While I personally like to put a few assertions just to find my typos quicker, adding additional fluff here is mostly detrimental. The kind of bugs that can happen with this sort of "dangerous" code are the ones that you basically just typos that you catch on the first run. I.e. it's not like there are any rarely occurring edge cases that are unhandled, since the code is extremely straightforward. The "complexity" is very low.
I think the last array entry {executeNoMatch , "A?"} will match on any string (and print the fallback "I don't know how to VERB" message), so it's impossible to fall off the end of the array. If you wanted to use a more defensive-programming style then you could add a sentinel of some kind and assert that you never hit it.
Overall I agree with you, my comment is just pointing out that this kind of tricks are dangerous, Cool McCool style, use at your own risk and so. Things you stop doing after your first million bugs fixed.
Well in fact I've tended more and more to this bare kind of coding as I've aged (and hopefully gained experience). Many of the seatbelts (like assertions) I've actually hit at some point or another (so they turned out to be useful in these situations), but on the other hand they allowed me to be more sloppy in my thinking, writing more complicated code, which I feel could be a net loss in productivity.
Then again this is just some example code on a website, so it's natural that it has to be done a little more straightforwardly than you would write it in actual practice.
It's natural to show people code as an example, which not write like that in practice? What's the example for then? Is there a disclaimer following, saying thaT the code is not how you would write it and mentioning all the things you would do differently?
Enlighten me please.
The array iteration code is also solid. Seems like a pretty good programmer, judging from the code you cite here at least.
While I personally like to put a few assertions just to find my typos quicker, adding additional fluff here is mostly detrimental. The kind of bugs that can happen with this sort of "dangerous" code are the ones that you basically just typos that you catch on the first run. I.e. it's not like there are any rarely occurring edge cases that are unhandled, since the code is extremely straightforward. The "complexity" is very low.