In some ways yes, in some ways no. Harold Treen gives some ways that it can be an advantage to use more lines of code. And for another example, it is easy to write a fast fourier transform in a few lines of code. But the most efficient algorithsm in terms of CPU time run to many hundreds of lines of code. For another example, you can write a very short algorithm to test for primality, just test it for divisibility by all numbers less than its square root -but it will be extremely slow for any number of any size. An efficient primality tester is likely to be a large complex program with many lines of code.
But - better programmers tend to use fewer lines of code at a higher level. For instance, if you do something more than twice in your program, chances are that it is best to write a separate routine to handle it. So then - that routine may itself be quite verbose, for maintainability reasons. But most of the time you just call that routine, so that's just one line of code.
While a beginner will tend to write the same code over and over with slight variations. And not give a lot of thought to ways that the coding could be more streamlined.
So - that's also a big part of the decision making you make when designing the architecture.
Good programmers write their programs with a good architecture. Bad programmers write complex architecture hard to understand and maintain. And as a result - end up writing far more code, to fit in with the complex architecture of the program.
There - the aim is not to reduce the lines of code as such. But to make it easier to read and more maintainable, and easier to write. Which often has the result of reducing the total lines of code.
As an example from my own code - just an example of a way that my code has improved - some time back I found a way to write a single line of code which
E.g. now, if you see the variable displayed in the right place in the program - you immediately know that it must also be persisting correctly to the .ini file, that the associated tool tip help will work okay, that it has been added to global undo, and that it can be saved separately as part of the settings for that individual window.
The result uses far less code than before and is more reliable and means that the user interface handling of user entered data has very few possibilities for bugs.
(There is a bit more to it, you also have to parse the user input - and in some of my programs I include that also in the same line of code, in others I have it as a separate couple of lines of code so making it easier to add extra processing).
Now the details will depend on your situation. I write in a very low level using plain Windows C. For many of you many of these features may already be built into your program in some way. But it's just an example to show how sometimes improvements in the coding may dramatically reduce the amount of lines of code.
It's always worth setting aside just a bit of time to think about the architecture of your program. And - not be shy of rewriting the architecture if you find a better way to do it.
What I do there is to first make sure it is all backed up of course. Then just dive in and change the architecture. It's surprising how sometimes you can make radical changes to how a program is organized with almost no repercussions at all. Other times, you try, and the whole thing ends up in a complete awful tangle and your brilliant architecture idea doesn't work at all.
But - you've got a backup. You've just put a few hours work into it. So, you roll back again.
Nothing as effective as actually trying it out to find out if the architecture works. Of course - your mileage may vary. And I'm a sole developer so can just do that at any time if I want to. Do it very rarely, perhaps every few years - but there've been a few times I've changed the architecture and been so glad I did it - such as for instance that one line method of adding user variables to the program - one of the best programming decisions I made I think :).
But back to examples to show that this process of reducing the lines of code can be taken too far. There are competitions to make surprisingly tiny programs to achieve a particular task, with the size usually measured usually in terms of the total characters in the program, but they often have surprisingly few lines of code as well.
Often deliberately obfuscated as part of the competition, but the very act of making it as short as possible (e.g. using single letter variable names wherever possible and using the C capability to redefine things with shorter names e.g. single characters for standard functions etc) makes it hard to follow what it does.
As an example, this tiny C compiler with only 2048 characters implements enough of the C language so that it is able to compile itself:
Obfuscated Tiny C Compiler
C code here: Page on bellard.org - which apparently when fed itself as argument outputs the compiled x386 code for its executable.
Or things like these: Obfuscated C Code
For more of this type of thing see The International Obfuscated C Code Contest
These programs are great fun. But not good models for programs that you want to be easy to understand and maintain.
But - better programmers tend to use fewer lines of code at a higher level. For instance, if you do something more than twice in your program, chances are that it is best to write a separate routine to handle it. So then - that routine may itself be quite verbose, for maintainability reasons. But most of the time you just call that routine, so that's just one line of code.
While a beginner will tend to write the same code over and over with slight variations. And not give a lot of thought to ways that the coding could be more streamlined.
So - that's also a big part of the decision making you make when designing the architecture.
Good programmers write their programs with a good architecture. Bad programmers write complex architecture hard to understand and maintain. And as a result - end up writing far more code, to fit in with the complex architecture of the program.
There - the aim is not to reduce the lines of code as such. But to make it easier to read and more maintainable, and easier to write. Which often has the result of reducing the total lines of code.
As an example from my own code - just an example of a way that my code has improved - some time back I found a way to write a single line of code which
- Adds a user variable (e.g. check state or the value of a parameter in the user interface) to the .ini file so that it is persistent when the user exits the program and starts it up again
- Displays that value to the user
- Adds that value to global undo for the program
- Records that variable as associated with a particular window or windows - so the user can save all the values for any individual window in the program
- Associates its id with tool tip extra help - which I can then edit within the program - several pages if necessary of extra help telling the user how to use that control and what it does.
E.g. now, if you see the variable displayed in the right place in the program - you immediately know that it must also be persisting correctly to the .ini file, that the associated tool tip help will work okay, that it has been added to global undo, and that it can be saved separately as part of the settings for that individual window.
The result uses far less code than before and is more reliable and means that the user interface handling of user entered data has very few possibilities for bugs.
(There is a bit more to it, you also have to parse the user input - and in some of my programs I include that also in the same line of code, in others I have it as a separate couple of lines of code so making it easier to add extra processing).
Now the details will depend on your situation. I write in a very low level using plain Windows C. For many of you many of these features may already be built into your program in some way. But it's just an example to show how sometimes improvements in the coding may dramatically reduce the amount of lines of code.
It's always worth setting aside just a bit of time to think about the architecture of your program. And - not be shy of rewriting the architecture if you find a better way to do it.
What I do there is to first make sure it is all backed up of course. Then just dive in and change the architecture. It's surprising how sometimes you can make radical changes to how a program is organized with almost no repercussions at all. Other times, you try, and the whole thing ends up in a complete awful tangle and your brilliant architecture idea doesn't work at all.
But - you've got a backup. You've just put a few hours work into it. So, you roll back again.
Nothing as effective as actually trying it out to find out if the architecture works. Of course - your mileage may vary. And I'm a sole developer so can just do that at any time if I want to. Do it very rarely, perhaps every few years - but there've been a few times I've changed the architecture and been so glad I did it - such as for instance that one line method of adding user variables to the program - one of the best programming decisions I made I think :).
But back to examples to show that this process of reducing the lines of code can be taken too far. There are competitions to make surprisingly tiny programs to achieve a particular task, with the size usually measured usually in terms of the total characters in the program, but they often have surprisingly few lines of code as well.
Often deliberately obfuscated as part of the competition, but the very act of making it as short as possible (e.g. using single letter variable names wherever possible and using the C capability to redefine things with shorter names e.g. single characters for standard functions etc) makes it hard to follow what it does.
As an example, this tiny C compiler with only 2048 characters implements enough of the C language so that it is able to compile itself:
Obfuscated Tiny C Compiler
C code here: Page on bellard.org - which apparently when fed itself as argument outputs the compiled x386 code for its executable.
Or things like these: Obfuscated C Code
For more of this type of thing see The International Obfuscated C Code Contest
These programs are great fun. But not good models for programs that you want to be easy to understand and maintain.
About the Author
Robert Walker
Writer of articles on Mars and Space issues - Software Developer of Tune Smithy, Bounce Metronome etc.Studied at Wolfson College, Oxford
Lives in Isle of Mull
4.8m answer views110.3k this month
Top Writer2017, 2016, and 2015
Published WriterHuffPost, Slate, and 4 moreHuffPost, Slate, Forbes, Newsweek, Business Insider, and Science 2.0