> if you have 3 ways to do something I'd go with the way I found easiest and, ideally, made the simplest to understand code. If one of the choices was obviously stupid or inefficient, I'd probably skip it. But, honestly, clear code is super important. I'll leave the fancy stuff for when it's needed. And even then, it usually smells wrong to me. I was writing something last week that was just *crazy* complicated. It was making my head hurt, tons of 2D arrays...nuts. I added what amounts to a temporary table and then queried against it. Boom! The task of preparing the summary data is now a nice clean task. The task of analyzing the data is now a distinct task, also nice and clean. The overall brain power required to sort through this stuff is way, way lower. It's just better. It actually runs faster, but that wasn't a factor. It didn't matter it took five minutes or all night.
When stuff is getting so complicated that I can't follow it easily or figure out how to test it, I'm bound to screw it up. That's usually a time to look at the problem again and come up with a different line of attack. Breaking things into smaller pieces, trying a different approach, figuring out what I don't understand so that I can simplify things, etc. Speed per se? I don't think about it much. Until I have to. Which isn't often. And fancy code tricks are not even in my top five approaches to speed problems these days. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
