>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, here, I argue against the overhead of invoking a UDF from within the context of a single atomic VFP command, not the 'work' of creating the UDF itself. I do not disagree that maintainability and readability suffer using the 'clever' one-liner, however, a call to a UDF is expensive relative to the use of a native expression in a clause, and may make the use of the native expression desirable, even if it's a bit unreadable. If the scope of the one-line statement were small, representing a small number of iterations, the UDF is clearly preferable.

At least I do qualify my acceptance of the unreadable construct by saying that if I resort to using it, I'd comment it! :)