* Anselm R. Garbe <[EMAIL PROTECTED]> [2008-05-12 11:35:54 +0200]:
On Mon, May 12, 2008 at 09:34:52AM +0100, David Tweed wrote:
On Thu, May 8, 2008 at 1:47 AM, Charlie Kester <[EMAIL PROTECTED]> wrote:
> * Christoph Lohmann <[EMAIL PROTECTED]> [2008-05-07 23:48:20 +0200]:
> With respect, focusing on lines of code is the wrong perspective.
> It doesn't matter if you see that number as an achievement or as
> an expense.
>
> If you make reducing LOC your primary goal, you end up writing
> Python or Ruby.
>
> I want:
>
> - small executables - simple, clean user interfaces (do one thing and do it
> well) - good performance
>
> When measuring smallness, it's important to include any shared
> libraries or runtime environments in the calculation. Many Python
> programs are only superficially small. (You could say the same
> thing about a bash script in comparison to a Bourne shell script.)
My personal opinion has always been that focusing heavily on reducing
the number of lines of code is almost as misguided as maximising the
number of lines you produce. Taken beyond the sensible level of
removing functionality that doesn't belong at the level of your
application, you end up creating code that embodies so many _hidden_
assumptions and dependencies on how other parts are implemented that
it's very difficult to modify.
To my mind, a well designed application should have exactly the
functionality that is best implemented at its level, no more and
equally importantly no less. If that requires more lines of code then
that's a price worth paying.
I agree, but still the SLOC is a related indicator if the
functionality has been implemented in a decent way at its level.
If a file editor (vim) consists of >200.000 SLOC, something is
wrong obviously.
Yes, it's an "other things being equal" kind of measurement. I didn't
mean to suggest it has no value whatsoever. Among other things, it's
clearly a major component of maintainability. I also agree that it
can give a rough indication of creeping featuritis.
Thanks for reminding me about vim. I've been intending to replace it in
my toolkit. While I'm at it, maybe I'll get serious about installing
dietlinux and getting rid of a lot of the GNUish cruft that I've
accumulated over the years.
