Is less code more productive/better quality/higher performance?

Question

Writing less code will give best productive/quality/performance! Is it true?

Answer 1

No, it is not.

Answer 2

Yes, it will.

Answer 3

Not necessarily, but more often than not yes. See The Best Code is No Code At All

Answer 4

Sometimes, but often not.

Answer 5

Yes, less instructions take (most of the times) less time. But don't drive it to extreme. (There are instructions that are very powerful but also require a lot of cpu cycles).

It is good practice to first develop the code and then optimize the bottlenecks. Because optimized code is often less readable.

Answer 6

Well - It depends..

You could write program in 10.000 lines of code that runs really fast, and also you could write program in 3 lines of code that could grind our server to a halt.

You should give us more details in order to get a right answer

Answer 7

in scripting languages (like javascript), script length indeed has an effect on performance. In "real" languages like java, a lot depends on your compiler. Two bits of code of different lenght might in fact get compiled to the exact same output. In that case, code length is not an issue concerning performance. For readability's sake - keep your code clean and simple, though.

Answer 8

"Code is not an asset, it's a liability".

Answer 9

Sure - when you write less you won't be

• adding errors or
• adding unnecessary load or
• wasting your time writing those things

But, the following quote from Einstein should also be bourne in mind:

Make everything as simple as possible, but not simpler see here

Answer 10

The best reason to not write code is that you're hopefully spending more time thinking about how to plan your code. If you take a couple of extra hours to write some use cases or flow diagrams instead of just hurling yourself into code you'll probably find:

• You're initial solution is sub-optimal.
• You've found a much more elegant way to solve the problem in less code anyway.

Answer 11

Writing simple code is probably better, but the question is, what is simplicity?

In "The Rise of 'Worse is Better'" by Richard Gabriel (http://www.jwz.org/doc/worse-is-better.html) we are told that there are 2 competing styles of programming - the MIT style and the New Jersey style. They have the following views on simplicity:

MIT style: Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.

New Jersey style: Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.

Should the implementation or the interface be simple? Yes.

When it comes to efficiency, there are also no easy answers - bubblesort is slow, but doesnt require much code, whereas quicksort is fast, but requires a lot more code.

Sometimes less code is less readable (for no reason) - for example when your colleague has removed all vowels in order to produce less code (!). Sometimes more code is less readable (for no reason), for example when your colleague has implemented sorting of a 10 element array that runs once every week as quicksort.

There are no universal answers. Just always beware that both computers AND human beings are going to read your code.

Answer 12

The smaller something is, the less there is to go wrong.

However, it can also mean it is more difficult to fix the bits that do.

It is usually good practice to try and write code that is concise.

Just remember that maybe the solution that you can code in 1 line or 100 lines is best written in 10 lines.

Answer 13

Usually you can say

Less Code == Less Bugs

as it's easier to make a bug in 100 lines of code compared to making one in 10 lines of code. The number of bugs usually raises with the number of code lines. So it may be higher quality.

Less Code != Higher Productivity

I can quickly hack something together in 100 lines of code or really spend a long time on analyzing a problem and coming up with a very tricky solution in 10 lines. So in one case I wrote 100 lines of code in 15 minutes and in the other case I wrote 10 lines in one hour. The 10 lines are probably much better than the 100 lines, however if my major goal is to get the app done as quickly as possible and nothing else matters, solving each problem in 15 minutes will get me there much faster than solving each in one hour, right? That the application may be a mess in the end is a different topic.

Less Code != Better Performance

Why? BubbleSort has less lines of code than Quicksort, guess which one sorts 1 Mio numbers faster. Quicksort will beat BubbleSort by a factor of 20 and more easily, depsite the fact that it's more code.

Less Code == Better Readability

Not always true, but in general it's easier to read a function with little code lines compared to one with plenty of code lines, isn't it? Of course if you only get the code small by using cryptic variable names, leaving out whitespace and comments, and by using hard to understand bit twiddling tricks where nobody can say what this code does without an explanation, this won't hold true of course.

Answer 14

In the words of Wil Shipley:

I ask you, grasshopper, which is better: flexible code or tiny code?

"Ah," you exclaim, "Learned master, it is a trick question: code which is tiny yet flexible is best!"

WRONG! Tiny code is always best. Now you must carry water up the hill for the rest of the day.

Answer 15

As a rule of thumb, (but this is very generalized answer, and should not be taken out of context) I'd say that that may be true for lower level languages (fortran, c, cpp) in which you do most stuff manually. For higher level languages (py, matlab, ...) who depend on their libraries/modules ... it often depends on the implementation of the functions, subroutines, classes (however you call them).

Answer 16

The answers on here are good. I'd just like to point out that you might not be asking an accurate enough questions.

Having DRY code is critical. By DRY, I don't mean "Never type the same thing twice" or "reuse code snippits from your high-school years", I mean that in a given project/codebase, each piece of business logic should exist in exactly one place, and that any patterns in code should be abstracted, combined, reduced to data driven, whatever it takes so that when you have to change a single thing, you only change it in ONE place.

So DRY code will make you more productive and better quality.

The amount of code doesn't mean anything taken alone (as long as your code is DRY, longer is probably better because it tends to be more readable)

Finally, you shouldn't worry about performance because you won't be able to affect it much EXCEPT by not being a horrible, terrible programmer. This means understand the massive degradation caused by inner loops, don't use a LinkedList if you are going to be indexing into the list, don't use an Array List for an insertion sort, etc, and know your language well enough to know when it's hiding these types of issues from you.

As an example of the last point: I saw an example of "Good" ruby code that caused an unnecessary inner-inner loop (3 levels nested); but the code was short and sweet--It was absolutely beautiful "Elegant" code that had just horrific performance when used beyond a trivial dataset. The language wasn't doing anything really, but it's elegance did tend to hide the code that did..

Answer 17

Programming is a mixture of think time were you think about what the problem is and how you you break into small bite chunks - individual components. Once that's all sorted out you cAn then get your hands dirtyand code.

Avoidingcode duplication should always be a goal. Code smell like cutting and pasting not only results in bad code but also highlights that thatdevdloper is probably taking other nasty short cuts becausetheydont know better or care because tomorrow it's not their problem.

Answer 18

It is a very loose correlation at best. A linear search function is less code than binary search one. It is also much slower. You can solve a function using recursion that is much smaller code wise but significantly slower and lower quality(i.e it crashes when it overflows the stack). Now in a language like python, it is more often true since the key to performance is to make sure you spend your time in C routines rather than executing python.