I have this doubt many years. I am wring some code to achieve some functionality. For example I am writing 20 lines of code to achieve the functionality and my co worker writing the code for the same functionality with just 5 lines. Since he used some looping statement to achieve that, but that code will execute around 30 to 50 times.
So which is best way of coding? As per my knowledge I always try to reduce coding length as much I can.
This answer must be very general but:
The first priority must be clarity. Usually concise code is clearer than long winded code, but, often not. So favour five or six simple easy to understand lines of code over one brilliant but obscure hard to read one-liner.
The second priority may be speed of execution, so you may want to re-factor your code if (and only if!) your code is running too slowly for the given requirements. (The brilliant but obscure one-liner may be much faster; on the other hand hard coding twenty lines with subscripts 0 to 19 can be faster than a for (x=1,x < 20 ;x++) loop ).
The other rule of thumb is if you cannot see the whole function in one screenfull (say 60 lines!) then consider breaking it up. Being able to see all the code in one eyeful really helps comprehension.
I am new to programming. I read some books about design patterns, TDD/BDD, unit testing and so on.
From what I understand more code means more potential bugs. Moreover, one of TDD/BDD major goals is to write enough code only to make the test pass. I am practicing TDD/BDD as much.
The only thing that lines of code measures is how many lines of code you have.
There are no hard and fast rules for how many you should or should not have; just use what you need to get the job done, make sure that it's reasonably sane and maintainable and that it has a low enough likelihood of making you wince when you come back to it in 6 months time, and you'll do fine.
Concise and Reduced code is
Better execution of code
Both of them, concise code and better execution are not comparable term. Better to have both. If you turn it a comparable term, then first priority is better performance.
Related Tutorials
Related Books
lines of code is too rough measure of code. Certainly long convoluted code can often be improved by shortening it, but at the same time short obfuscated code can often be improved by lengthening it.
The critical thing to understand is that the length of the code is actually a symptom in this process, the primary concerns are symmetry (fairly objective) and readability (fairly subjective) and finally performance (objective)
symmetry
Any time you improve code by shortening what you are actually doing is exploiting some symmetry in the code. I.E. two or more bits of code are doing something which is the same in some way, they may be completely different in other ways, but if you can separate out the code which is the same you can remove the duplication.
readability
This is inherently subjective however generally people agree that longer descriptive names are better than shorter ones. Less specific, more general code can use shorter more generic names as there is less to describe, but any time you have a specific meaning specific naming helps.
performance
after you have looking at the clarity of your code the next question is is it fast enough? At design time you can look at complexity of structures & algorithms and hopefully prove that you are at least in the right ball park. To fully answer the question though you need to measure the implementation. Only if the measured performance is not good enough is it worth going back to optimize your bottlenecks.
