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.

closed as not a real question by gnat, Tom Squires, Walter, Robert Harvey, user53019 Nov 7 '12 at 17:28

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üller Nov 7 '12 at 10:28
  • performance more important for me. – TinTin Nov 7 '12 at 10:31
  • 3
    There is no generic answer, this isn't how programming works, there is no silver bullet. – yannis Nov 7 '12 at 10:34
  • 1
    @Ayyappan.Anbalagan if you are looking for a generic answer then: "It depends..." – Songo Nov 7 '12 at 12:28

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.

  • 3
    + 1000000000 for The first priority must be clarity – Tulains Córdova Nov 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 Fellows Nov 7 '12 at 14:46
  • @Donal Fellows -- I did use the weasel word "consider". :-) – James Anderson Nov 8 '12 at 1:58

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.

  • 1
    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 Franken Nov 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... – haylem Nov 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"). – herby Nov 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.


Concise and Reduced code is

  • Clear
  • Easy to Understand
  • Easy to Debug
  • Easy to refactor

Better execution of code

  • Performs/plays important role for better user interaction
  • Time saving and gives better outcome.
  • Ultimately we do code for faster performance.

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)


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.


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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.