>>I have some fields in a table. I want to check this bunch of fields to see if they are all EMPTY(). What's the best way to do it? Maybe I need to use EMPTY() instead? But I was comparing one after another and it was not very efficient. Thanks in advance.
>
>You've gotten a ton of replies giving shorter, more cryptic ways of doing things. I'm now going to recite sermon # 1,937, "Clever one-liners are bad!"
>
>We had this discussion about a week ago; JVP posted a semi-cryptic one-liner, and a UDF with a CASE statement that accomplished the same thing, and asked "Which is better?" The respondents whose opinions I value, mine, Jim Booth's, and Christof Lange's were an interesting perspective.
>
>All three of us said that where the number of repetitions was unimportant, the UDF was the better alternative, because its intent was clearewr and it was more maintainable and extensible. I went on to say that the one-liner offered advantages in a WHERE clause of a SQL Select or a FOR statement, for no reason other than the UDF overhead.
>
>I was right; the UDF took nearly twice as long to execute as the one liner. This amounted to a 3 second difference in execution speed in 1,000,000 iterations. Oops. The performance cost was more than recovered the first time someone else had to look at the code and figure out "whut duzzit dew?"
>
>Sacrificing clarity for speed is a bad tradeoff, especially where the speed increase is minimal. Get things working in an understandable, well-documented, boringly obvious fashion first; if speed is a problem, and there are clear indications that the problem lies in an area where a less obvious, more obscure approach, try it, but leave the obvious, easy approach there commented out, and document what you do heavily.
>
>Coding, contrary to popular belief, is (or should be) relatively boring and consistent. If there are five ways of doing something, I tend to use one way all the time, so that the next guy in has a clue about how I'll implement something - once he understand my approach to implementing something, he won't be confronted by another equivalent but syntactically different block of code just because I felt like doing it that way. I'm even more appreciative of my lack of original thought when I'm the guy picking up the code a year or two down the road...
>
>I've never gotten a job because I could code in 5 lines what someone else needed 10 line of code to accomplish. Plenty of my clients hire me because once I've got it working someone else can figure it out.


Agree completely Ed. Terrific post.