More interesting stuff from the lesscode.org site:
It is becoming increasingly difficult for me to envision why would anyone not consider lesscode much more desirable than morecode? Software code is like the headcount: you typically only hire as many people as you need in order to successfully run your business. Anyone that might suggest to you that it is much better to double or triple your payroll, ‘just in case’, is simply hosing you.
I’m a firm believer in trying to write as little code as possible (check Paul Graham’s arguments and tell me whether you don’t find them convincing), but one of my very smart colleagues raised a valuable point: Fewer lines may be a lot harder to understand. If you take a look at some of the wizardry that is feasible with Lisp macros and the like, it’s hard not to concede the point … It’s basically the same argument about whether
if (a == 0)
b = x;
else
b = y;
or
b = a == 0 ? x : y;
is more readable, easier to maintain etc. If you know the ? operator, the answer is obvious; but if you imagine that it was not part of the languages with C ancestry, but instead invented by some programmer for a particular project, the answer might be different.
First, if you don’t know the tenerary operator and you’re reading code in a C based langauge, you’ve other problem. This is not a problem. The problem is something like this (C++):
set1 <<= set2;
vs.
set1 = set1.Union(set2);
Or evil code macros.
Second, concise code is /usually/ better, but not when terseness is the goal.
It’s better to say something in as few words as possible, but not fewer. Sure, I can do: !boolValue, and my eye often just skip the !, so I usually do boolValue == false to make sure that I see it.
Other nastiness