Hi Ed,

>In general, the individuals using them tend ton be more slef-impressed with their cleverness than they are in having the solution understood.

Everytime you think that code is clever, this should raise a red signal. Code should not be clever or thrilling, but boring and predictable. If I were a novelle writer, I'd would do the opposite, but I'm a developer.

In team development that's even worse. If someone considers self-expression in source code an important topic, how much would she care about other priorities setup by the project lead?

>I'd use the one liner to avoid the overhead required by creating a UDF contianing nothing more than an LPARAMETER, the CASE statement, and a RETURN. And comment the code heavily.

May I disagree here? No creating a UDF can be a viable solution for many reasons, but the overhead of creating it is definitely not a good reason. You might decide to use inline code for speed reasons after you've tested that it indeed has an impact. Or might face the 128 DO level limitation and therefore not create a UDF, but otherwise a UDF increases maintainability, clarity, reusability and tends to be less bug-prone, because you can test it separately.

Christof