In programming, why are more lines of code sometimes considered "better"?

Question

A person might say, "oh, my software was 10,000 lines of code" or something, but isn't this really meaningless when you can get the job done with less? (like using loops instead of typing out each possibility)

I would have thought using less lines would be better if anything.

Answer 1

Don't ever focus on the length of source code. It rarely determines a program's quality. If an application is running poorly, writing better code could warrant more or less lines depending on the situation. Also, writing less lines does not necessarily yield better results. It's all about balancing functionality with performance.



Focus on the problem at hand and get the job done. If it's running poorly, research ways to speed things up. Pay no attention to those who claim their 10,000 line application is a masterpiece. I guarantee with that many lines, there is plenty of room for mistakes.



:)

Answer 2

In Summary Following are the Top reason that sometimes Software Codes should not be CRUNCHED:



1. Performance: A small Code Does not ensures that it will give you optimal results in terms of MEMORY complexity and Time Complexity.



For example, in an Image Processing Application, Loading Whole Image into buffer will Degrade performance when even small portion of it can do the job.



Another example is Writing recursive code can REDUCE the amount of lines but may affect system stack memory.



2. Maintainability: Some programmers have bad practices such as Writing very "Tricky" codes and think this reflects there intelligence. But this is bad. Consider a scenario: What would happen if such programmer who wrote 1000 line of software application and one day leaves the company. The programmer newly engaged would FURIOUSLY abuse/curse the previous programmer for poor commenting and "Tricky" shortcuts used in writing functions.



Some bad practices include Long Nesting Of Codes, No Commenting.



It may even be the case during development that as developer proceeds, he may forget the Logic behind the functions!!





3. Programming Hazards: Sometimes when shortcuts are used in programming, they mat cause serious failures such as stack overflow, deadlocks. This is mainly case in Network programming & Mulch-threaded Programming.

Answer 3

The length of code is irrelevant. What matters first and foremost is maintainability. After that comes optimization. The length of code in either of those can vary and doesn't matter one bit, because the line count isn't what gets put into your program. The compiler's translation of it is. Even optimization can sometimes produce MORE code than slower-performing easily-read code. Whether you use a ternary operator to condense a conditional check into one line, or use an if-else statement that spreads across a dozen lines, doesn't matter. The net effect is the same, so do what is easier to maintain. When you write code, write it so that it is easy to read and follow, and easy to maintain or expand. This will save a crazy amount of time and resources when you or another programmer has to go back and look through the code to fix a bug, update content, add features, or convert to a different platform. Anyone who focuses on the amount of lines in their code is a retard and probably a sh*tty programmer, or they were using that to implicate the size of the job, not as a measure of efficiency in code.

Answer 4

Actually, most of the time, fewer lines of code are better. If you can get something done efficiently, that's better than wasting code (since that will at least make the code harder to read, and may also use more resources during execution). On the other hand, sometimes you can increase runtime efficiency by using a more complex algorithm (using more lines of code). I think when people say their project has however many lines of code, they're not bragging about how much code they can write or used for the project, but rather the scale of the project, i.e. 'this many lines of code were necessary, so it was a large and therefore challenging project'.



Of course, it is often a good idea to put different things on multiple lines even if the compiler or interpreter doesn't strictly require it, to improve readability. For instance, consider which of these three Javascript function definitions you'd prefer to deal with:







function collapse_null(arr)

{

var ahead=1;

for(var x=0;x
{

if(arr[x]==null)

{

var next=x+ahead;

while(arr[next]==null)

{

if(next>=arr.length)

{

return;

}

ahead++;

next++;

}

arr[x]=arr[next];

arr[next]=null;

}

}

} /*22 lines*/







function collapse_null(arr)

{

while(true)

{

var a=0;

var b=arr.length-1;

while(arr[a]!=null)

{

a++;

}

while(arr[b]==null && b>=0)

{

b--;

}

if(a>=b || b<0)

{

return;

}

arr[a]=arr[b];

arr[b]=null;

}

} /*22 lines*/







function collapse_null(a) {var e=null; var b=1; for(var c=0;c=a.length) {return;} b++; d++;} a[c]=a[d]; a[d]=e;}}} /*1 line*/







The first two are both 22 lines, and the third one is only 1 line. But the first one is clearly the best.

Answer 5

Anyone who brags about the number of lines of code in their software is an idiot for two reasons:

1. It's not about the amount of code, it's about what the program does and how efficient it is at doing it, and most of the time less is better.

2. I can make a simple, 30-line program that reads a file and outputs it on the console a 500 line program by adding a lot of unnecessary new lines, functions, and comments.

Answer 6

The presumption is that the "10,000 lines of code" were well written. It is just a statement of the size of the programming task.

Answer 7

That's not the implication. They're just saying how big the job was.



Let's say you had to clean a bunch of junk out of the back yard. You might say "I took 20 bags of trash to the dump". You're not saying that 20 bags is better than 10 bags but rather just describing how big the job was.