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.

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

6

I don't think this is answerable unless we see the actual code.
–
Yannis♦Nov 7 '12 at 10:27

1

"more effective" in what context? performance, readability? How important is performance in your context? It's a difference if you rite a website where minor differences don't matter that much or have code that processes large amounts of data in real time.
–
thorsten müllerNov 7 '12 at 10:28

5 Answers
5

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.

+ 1000000000 for The first priority must be clarity
–
user61852Nov 7 '12 at 11:49

Short functions are a nice-to-have, but it doesn't necessarily help all that much to decompose a complicated piece of functionality into a large number of short functions that join together in a complicated pattern. That's just turning code spaghetti into code ravioli; you're still stuck with the pasta…
–
Donal FellowsNov 7 '12 at 14:46

@Donal Fellows -- I did use the weasel word "consider". :-)
–
James AndersonNov 8 '12 at 1:58

It depends: You can make your requirement only functional but you can also add a performance test. You write your tests based on the real world requirements in the end. If a requirement is: "Load webpage in 5 seconds max" then you can do TDD and it just becomes a part of your tests. If you find out that this part is a bottleneck you can even add (next to the general 5 seconds test) add a specific test for performance of this piece since it became a bug (let your tests fail). So you write a test for that part and done. For now and the future.
–
Luc FrankenNov 7 '12 at 10:38

2

Also, you'll come to meet some coders who can write very terse code and yet pack a high number of bugs and WTFs in it. Usually we'd point at Perl gurus for the canonical example of this abuse, but it can be achieved with any language...
–
haylemNov 7 '12 at 10:49

"one of TDD/BDD major goals is to write enough code only to make the test pass" Well, don't confuse tools with goals. Major TDD/BDD goals is good code design. "enough code only to make the test pass" is only a one of the tools to achieve that, but it's only half of the equation, the other side being you incrementally add more tests, until the code does what it should (or, as IIRC Ward Cunningham pointed and Kent Beck included in the book, "until fear transforms into boredom").
–
herbyNov 7 '12 at 13:44

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.

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.