>OTOH, more often than not shorter code is faster,

>I thought that we already agreed that this was not the case.

We agreed that it was NOT NECESSARILY the case, but more often than not, in practice, it IS faster to have less code.

> but more importantly, better maintainable.

>ROFL and LOL!!! I could not disagree more. Very often, I have seen developers who have tried to be too cute and packed several function calls into a single IF statement. Not only is it hard to read, but when you step through the code trying to debug it, you have a hard time trying to find which function is the one that is failing.

There is a difference, between less code and cramping everything on one line (compactness). In any case, readability should win over compactness. That being said when look at old code (including mine), too often large parts could be cut out if you organize things better and different. Especially in loops, it can easily become a nightmare if there is a lot of code in there. Finding the errors when a conditional counter is being missed under a certain condition is finding a needle in a haystack.

If you have taken notice of my SQL contributions, I strive for the least code, which usually is faster or equivalent to longer SQL code.
The less joins, cte, subqueries, the less characters in a SQL statement are a strong indicator for simplicity, readability, and again... more often than not also an indicator for performance.

Speaking of SQL...

When it comes to analyzing data, some will take a DO WHILE ... SKIP... or SCAN .. ENDSCAN to calculate multiple variables, possibly with LOCATE's or SEEKs in there. I'm sure you've encountered those situations. Horrible to maintain. Why not trying to put that into a single SQL statement? Why ?

If the outcome is wrong, you only need to look at the SQL statement, not to weed through a long loop to see what is going on, on a record by record basis. You can capture a single SQL statement from the SQL profiler and analyze and debug it in SSMS. Just one single point of failure, not a 100 line long SCAN... ENDSCAN solution.

I've been there, done that... writing a huge analysis program for different governmental bodies at several countries where the demanded statistical data was different each time. Moving the analysis from procedural fox code to SQL code made a HUGE, HUGE difference in maintainability. The code got much and much shorter, easier to read and if the values were wrong, you'd immediately know where to look. Not a 100 lines, but only a one or very few points in the program.

In my book, the less code... the less errors, the less problems reading the code thus the less problems in resolving errors.

And you're right... sometimes you'll have to write more code to make it faster... but those should be the exceptions IMO.

YMMV