Take the 2-minute tour ×
  • Why is the length of a program important?
  • What difference does it make? [Aside from the fact that a short program looks "good".]
share|improve this question
Less is more. Chances are good that many libraries are better tested than your code, so try to use libraries, organize code, and write little of it. vetta.org/2008/05/scipy-the-embarrassing-way-to-code –  Job Dec 8 '11 at 18:39
Do you have a source (anecotal or not) for the original assertion? Also, are we talking code quantity, running time, development time, individual method length...? Needs some context. –  Steve Evers Dec 8 '11 at 19:36
add comment

migrated from stackoverflow.com Dec 8 '11 at 18:29

This question came from our site for professional and enthusiast programmers.

4 Answers

There are several different measurements of software complexity. Some are related to the length of the code.

For example:

  1. LOC (Lines Of Code) - directly measuring the length of the program to assess its complexity. It has been found in research that the amount of defects in the program relates to LOC. Meaning - the longer the program the more bugs you have in it.

  2. SC (Statements count) - the amount of bugs is tied more tightly to SC than to LOC, but the more statements you have - the more lines of code you usually have. In some languages you have to put a single statement per line, in others you don't, but people still usually don't put more than a handful of statements in a single line.

  3. CCN (Cyclomatic Complexity Number) and SCM - the amount of distinct execution paths in the program, directly tied to its testability. Longer programs tend to have higher CCN values (not necessarily, but very likely). CCN is affected by branching statements (like if, while, switch, for etc) which are usually affecting the LOC as well.

That's just several examples of measurements where the length of the program is likely to make the program measured to be more complex. The more complex the program is the harder it is to test it and uncover the bugs.

There are also things you can't quantify:

  1. Readability - hard to read, trace and debug a very long program.
  2. Maintainability - hard to change and fix a long program. It is also a problem when every single fix affects the whole code, while breaking it into pieces allows fixing and replacing a part of the program without affecting the rest of it. It also means that every small change will lead to extensive regression testing of the whole code.
share|improve this answer
add comment

Length has a number of important indicators. If I had to pick the most important, it would be that the bigger a program is, the more complex it is. And the more complex it is, the harder it is to fix when it breaks. I would say for most developers, fixing code that has already been in the field takes a lot more time than writing new features. So getting an idea of exactly how much maintenance you have to do is very important for project analysis.

Of course, the estimated size of a program gives you an idea of how long it will take to write. The size of the program probably has sometime to do with the resulting machine code, which may be a factor.

share|improve this answer
You can make a simple program extremly long. The amount of code does not determine how complicate the program is. I can make a software that is a 500k lines look better then your 50 line peice of sofware. I also guarantee you that those 50,000 lines will be well documented and easy to under, if its complex and hard to understand, then the code should be rejected. –  Ramhound Dec 8 '11 at 18:41
I agree that size and complexity are linear in all cases. However, I do not believe you can make a 500kloc piece of software that is less complex than a 50 line piece of software. I refuse to believe there is a piece of code 10,000 times larger that is less complex or easier to maintain. 10 times? Maybe, depending on who wrote it and what the conditions were, sure. 100? Doubtful, but I wouldn't 100% exclude it. 500? Guaranteed to be more complex. –  corsiKa Dec 8 '11 at 19:04
@Ramhound and glowcoder - the definition of complexity can be changed. One can define complexity to be a measurement of a size of the program, and then 500k will definitely be more complex than 50 lines. See my answer about the various definitions of complexity and related measurements. Point is that there's no single definition of what constitutes a complex program. –  littleadv Dec 8 '11 at 19:22
@littleadv That's true, there are multiple definitions. I don't think there's a definition out there where adding additional code does not increase the complexity. –  corsiKa Dec 8 '11 at 19:38
There are in fact several definitions where adding additional code doesn't (necessarily) increase the complexity. CCN is one of them, for example. If the added code doesn't have branching, the complexity won't change. –  littleadv Dec 8 '11 at 19:54
show 2 more comments

It's not the size of your program but what you do with it that counts most.

But size is a valid secondary consideration. Implications include:

  • The larger the program, the more likely it has significant defects.
  • If the program handles valuable or sensitive data, the probability of exploitable security defects increased.
  • A larger program generally consumes more resources. Memory is the prime one, although larger programs increase the chance of longer code paths which eat up CPU.
  • The more features a program has, the more any one customer pays for features they do not need. There is always a tension between bundling lots of functionality into one delivery package ("It's integrated!!!") versus including features the core user base does not care about ("Its bloated!!!").

Generally, defects lead to outages and support costs so many managers and users are understandably wary of large code. But remember that "large" is relative. What is large for a code editor versus a word processor versus a graphical page layout tool are different measurements. The objective is not absolute size but rather appropriate size.

My rule of thumb is that no program is finished until there is not one single thing that can be removed without affecting required functionality.

share|improve this answer
add comment

The length of a program is unimportant. It will mainly reflect the complexity of the problem that the program solves. What is important is the length of classes and methods. Generally, aim for classes that has only one concern, and aim for methods that only does one thing. Consider 20-line methods long and try to do something about it (I know this sounds extreme). If a 20-lines method does two things, prefer two 15-liners that does one thing each. Then you will get code that is easier to read, test and refactor. This approach will usually mean more lines of code, but I would chose this over monster methods in monster classes anytime.

share|improve this answer
My experience is that shortening classes and methods, while increasing their number, results in shorter code. Those little methods are reused surprisingly often. –  kevin cline Dec 9 '11 at 6:26
add comment

Your Answer

