

How important is it to reduce the number of lines in code? - footpath
http://programmers.stackexchange.com/questions/185925/how-important-is-it-to-reduce-the-number-of-lines-in-code

======
Paul_D_Santana
The #1 most important factor in coding is:

Will I be able to read my code tomorrow or next week and know what in the heck
I did?

~~~
timr
Which really means: did I spend the time to write good comments?

People will go to endless lengths to make their code more terse and/or "self-
documenting", but almost nobody takes the five extra minutes it takes to write
an intelligent comment. The comments are far more important.

~~~
jamesaguilar
I don't really agree. Which is to say, good comments are helpful, but they are
a flashlight in a dark room. If there's lots of furniture and clutter in the
room, you still might trip over something.

How many times in your codebase have you seen a comment like:

    
    
        // This exists because that dumb thing happened, 
        // and during the migration from Y to Z we had to 
        // support these two systems simultaneously. This
        // component mediates between the two . . .
    

And someone had added some common logic into the mediator, then someone else
had hooked into that, and now there's a snarl.

The most important thing is that the system be as simple as it can while still
performing its intended functions. We have all made a first cut at something
that ended up being three times as verbose or complicated as our second. You
want a system made out of pieces of the second kind. That's even more
important than comments.

I can definitely understand the desire to reduce lines of code, because it's
often a good _proxy_ for understanding how complicated a system is. Not
always, but most of the time, something a quarter as long that does the same
job is doing it a simpler way.

~~~
timr
That's an easy question: it almost never happens. The most frequent occurrence
(by far) is that there are no comments at all, just a wall of indecipherable
code. Even an old comment describing intent and usage is better than no
comments at all.

In your example, even if that comment is outdated, it's still _incredibly_
useful. It tells you, in under 5 seconds, the _original intent_ of a piece of
code, and how it was supposed to fit into the entire system. That's something
you'll never get without a comprehensive understanding of the project, which
takes far more than 5 seconds of reading. The real problem here is not that
there is a comment -- the problem is that a bad coder _fucked up_ by not
updating the comment. There's no excuse.

That all of the commenters below will spend _paragraphs_ explaining how they
shouldn't have to document their code with the occasional descriptive comment
is an amazing testament to the overwhelming power of human laziness and self-
delusion.

~~~
jamesaguilar
My point is not that this comment is unhelpful. My point is that it would be
better if the _reason_ for this comment's existence were eliminated. I.e. that
the removal of unnecessary complication in the system is an even more laudable
goal than commenting well.

Obviously, both will have a part in any well written an maintained system. But
the person I'm responding to held good comments up as _the most important_
aspect of system maintainability, and that is simply not the case.

~~~
timr
You were responding to me, and no, that's not what I meant. ;-)

I'm not saying that comments are the "most important" aspect of system
maintainability, but that they're one of a few things that are all of top
importance.

Obviously, if you write spaghetti code, your system won't be maintainable, no
matter how many comments you write. But that's a false dichotomy: you need to
write good code _and_ you need to write good comments. Neglecting either one
leads to unmaintainable systems.

------
dchichkov
Every line of code is a constraint working against you.

~~~
baddox
.split("/n").join(";")

~~~
hayksaakian
sorry for being pedantic, but should'nt it be "\n" ?

~~~
1337Coder
sorry for being pedantic, but should'nt it be shouldn't?

------
dvt
Things are complicated, but it's a well-known fact that lines-of-code is
literally the worst metric of source-code health. Lines-of-code have been
previously used as a productivity metric and as an efficiency metric, but in
the past several decades, LOC has been debunked as virtually worthless in both
cases.

In other words, if you're thinking "that guy must be productive, he wrote
twice as many lines as this other guy" or "this code must be slower since it's
3 times longer than that code" you're most likely wrong in both cases. Or, in
the best case, very naive.

And what's up with Ars Technica just copy-pasting SO (or prog.SE) answers into
an article?

------
k3n
It has everything to do with context, and the ultimate goal should be clarity
for the reader. But, I also don't think you should ever compromise any non-
trivial design for the worse to 'make it more readable'. Sometimes clever code
can't be easily avoided, whether it's due to language limitations or the
general design pattern itself, so proceed with caution and use lots of
comments in those cases. A quick example here would be a factory method: since
you're often referring to abstracted resources, you can't really make a non-
clever factory without entirely defeating the purpose of the factory.

Another example would be from PHP, where you can many times do tasks in
several different ways, and so you may have this code (straight from the
manual) for reading the contents of a file:

    
    
        $filename = "/usr/local/something.txt";
        $handle = fopen($filename, "r");
        $contents = fread($handle, filesize($filename));
        fclose($handle);
    

And this isn't even very descriptive, unless you have a background in other
languages such as C to grok that filesize($filename) might mean "read to the
end of the file".

OTOH, this code does the exact same thing and is extremely explicit about what
it's doing:

    
    
        $contents = file_get_contents("/usr/local/something.txt");

------
just2n
Reducing the number of lines isn't important. Unless you're code golfing or
otherwise competing to fit within a certain code/binary size, you should never
care about line count at all.

The only thing it will do is cause you to crush your lines wherever possible
and code horizontally instead of vertically, which generally conflicts with
readability. In fact, I'd actually impose a limit on line length to prevent
just that.

Instead, write code that makes sense when you read it. Avoid cleverness, and
DRY. Repeating yourself in the way that violates DRY principles can often make
reading code more difficult because you're essentially forced to re-read
repetitive code because you can't assume it's all identical.

The only exception to this is code standards for consistency in the code base
that make sense, such as use a '{' on the same line as the definition or omit
the '{}' block if the body is just 1 statement in cases where you won't
violate a width constraint, etc. Anything that isn't completely reasonable as
a code standard is optimizing for line count and is probably the wrong thing
to do.

~~~
just2n
Downvotes on this?

Be thankful downvotes are anonymous. You are very likely incredibly
incompetent, and I fear for anyone who has to read your code or worse, _use
it_.

------
jfaucett
personally, i think that when you're programming, not just pondering how to
make your code simpler and shorter but also concentrating on patterns that
repeat and packing them into a catchall solution can do a lot towards making
code more readable and maintainable. I suppose this is what is usually meant
by DRY, but I unfortunately still see an aweful lot of code that doesnt follow
this principle. And i think it has to do with the fact that many (myself
included) programmers think about solving the problem at hand and we sometimes
allow our thoughts about abstracting what we're doing into overarching
reusuable procedures to slip into the background.

for instance, say you notice you've got multiple for loops iterating over
matrixes of pixel data and running transformation functions on member
elements. The first level would be to abstract this into an each function
taking the array and the function to call, the next step would be to pack the
each into an even more general function, and now all those lines have been
compacted into a single call pixel_data.update_array_matrix.

------
Manishearth
Depends. Does it make it cleaner, faster, and more readable? Go for it. Does
it just use syntactic sugar to cram stuff into one line? Don't do it.

------
deliminator
Following quote comes to mind (Dijkstra) "...we have to keep it crisp,
disentangled, and simple if we refuse to be crushed by the complexities of our
own making..."

I found his use of the word "crisp" very interesting. I believe it means to
keep your code short and to the point, without any extra embellishment.

------
mark_l_watson
I have actually been programming since I was a kid (I got access to computers
around 1962). I used to write _huge_ blocks of comments, and even simpler
programs had a high LOC count.

I work differently now. I mostly work in Clojure and I write very few comments
but I like long and descriptive function and variable names. I think that a
concise language like Clojure or Ruby, combined with very good semantic naming
works much better for me. I can look at year old code, and fall right into it.

------
RougeFemme
LOC is also used as a "maintainability" metric. Don't know how useful it is. I
assume it would need to be massaged with some other metrics - or at least
placed in proper context, whatever that means in your environment. Also, if
your code verges on throw-away, maintainability would not be a consideration.

------
codygman
The only metric you should work on reducing in your program is complexity.

Of course, some complexity/warts will be needed.

------
niggler
What exactly did Ars Technica contribute to this discussion? It looks like a
copy-paste job.

