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.<p>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.<p>And what's up with Ars Technica just copy-pasting SO (or prog.SE) answers into an article?
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.<p>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:<p><pre><code> $filename = "/usr/local/something.txt";
$handle = fopen($filename, "r");
$contents = fread($handle, filesize($filename));
fclose($handle);
</code></pre>
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".<p>OTOH, this code does the exact same thing and is extremely explicit about what it's doing:<p><pre><code> $contents = file_get_contents("/usr/local/something.txt");</code></pre>
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.<p>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.<p>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.<p>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.
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.<p>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.
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..."<p>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.
I have actually been programming since I was a kid (I got access to computers around 1962). I used to write <i>huge</i> blocks of comments, and even simpler programs had a high LOC count.<p>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.
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.