>>In my opinion, writing code that's a little less efficient in places where it's okay to be less efficient, so long as the reason you're doing it is to be more clear for maintenance, shows signs of being a mature developer. You recognize that emphasis on speed needs to go where it needs to go, but not where it doesn't. In those places where it doesn't need to go you can use a better coding style, and that's the correct way to go.
>>
>>This is just my opinion, of course ... but I'm probably right. :-)
>
>I'm often maintaining other people's code. It's neither clear, nor fast, ever. Some of the things that were attempted were not for speed and resulted in the worst debugging issues.

Most of the issues maintaining other people's code is either they're trying to do 'cute coding', as in "See how smart I am, I came up with this convoluted solution!"; or they're trying to follow the "this is the best way to do this NOW" model of coding.

Granted, I've coded up with some ugly children in my time (and dressed them funny too), but 99% of them have a comment that reads "The following is ugly, but it works for the parameters given" with a list of the "are you kidding me?" requirements for that particular chunk of code.

I discovered that FoxPro (and VFP) ran best under the KISS principle; besides, to quote Montgomery Scott "The more they overthink the plumbing, the easier it is to stop up the drain"