Biz & IT —

How important is it to reduce the number of lines in code?

Is brevity the soul of good code?

Stack Exchange

Ankit works in J2SE (core java). During code reviews, he's frequently asked to reduce his lines of code (LOC). "It's not about removing redundant code," he writes. To his colleagues, "it's about following a style." Style over substance. Ankit says the readability of his code is suffering due to the dogmatic demands of his code reviewers. So how to find the right balance of brevity and readability?

See the original question here.

Minimize your potential for failure

Erik Dietrich Answers (51 votes):

I agree with your code reviewers, but with an asterisk. Each statement that you write in your code is a technical liability—it's a potential failure point. If you write a method with 10 statements and your coworker writes one that achieves the same functionality with 5 statements, his is likely to be 'better' as measured by likelihood of issues (there are twice as many places your code can be wrong, overly complex, or problematic).

Here's the asterisk, though. It's not about the actual number of lines of code in the idea because you can reduce the number of lines with something like:

void someMethod() {

This is one line of code, but it's a place where an amazing amount of things can go wrong. So I'd say focus on doing the most with the fewest statements—write as much code as you need to get things done and no more. At least, I think that's what your code reviewers are driving at.

Personally, I think there's a balance to be struck. As I said, each statement that you write is a liability, but if pulling out a local variable with a descriptive name makes your method a lot clearer and more readable, then there's a case to be made for that too. I think you can easily get into situations where people are quibbling over relatively minor aesthetic differences, but on the whole, I think your reviewers have the right idea—favor minimizing the number of things that can go wrong.

Related: "How do you cope with ugly code that you wrote?"

Let form serve function

Xion Answers (11 votes):

Taking the reviewers' advice literally won't do any good, because the obvious direct result is promoting terse one-liners (line length limit notwithstanding). I believe the lesson to be learnt here, though, is to make your code do fewer things.

In other words, this is a call for simplicity. It is quite popular claim that code is a liability, not an asset, so reducing code while preserving the functionality is a noble effort. This can be achieved by a direct, more down-to-earth approach that addresses the problem directly and prefers concise solutions.

Like Ken Thompson once said: "One of my most productive days was throwing away 1000 lines of code."

Easy-to-read code is the best

Joshua Volearix Answers (4 votes):

I currently work as a senior applications developer and project business analyst for a major company and never has the line count of my development been a center of interest. However, I believe that the more condensed a code can be, the better, BUT not at the cost of being able to quickly analyze and correct (or add on to) it. To me, when you are in charge of a business critical application that MUST have a vast level of scalability and be capable of on the fly alterations in a non-stop changing environment, concise, easy to read code is one of the most important elements in development. To the credit of Erik Dietrich's reply, this:

void someMethod() {

would be completely unacceptable to me. However, I found altering all the companies' existing code from:

if (boolean == true){
value.prop = option1;
value.prop = option2;


value.prop = boolean ? option1 : option2;

was an excellent code condensing choice that doesn't sacrifice readability.

As far as how it effects the code? I have never noticed a performance increase or decrease from, let's say, 100 lines of code. The simple fact is that it's more the process you utilize to arrive at the final product than the number of lines it takes to arrive there. I have seen some processes written in a very condensed way perform differently than longer codes with better code flow.

LOC count isn't an effective way to judge code

Dino Octavian Answers (3 votes):

IMO, it's a bad idea to measure code effectiveness by a trivial LOC count. There's a lot more to what makes properly engineered and effective code.

In my experience, effective code:

  • Doesn't break any of the SOLID principles
  • Is readable and self-explanatory.
  • Passes Albert Einstein's test of simplicity: "Everything should be made as simple as possible, but not simpler."


You must to comment.

Channel Ars Technica