Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm currently working on an indie project, so I don't exactly have the luxury of throughout human testing or external code review — however, I don't see any difficult bugs in my current code (I fix them as I see them, and most of the time they're just wrong field names and such, things that you fix in a minute or two), and I test it after implementing any feature before pushing it. Lately my LOC number was about 400 a day (for the record, it's C#), and I'm not only implementing new systems, but also rewrite things I've already written and fix some bugs.

Should I be bothered? Is it the sign that I need to stop and review all the code I've been writing up to this date and refactor it?

share|improve this question
    
how are you measuring LOC? does it exclude visual studio generated code or not? –  jk. Mar 12 '12 at 9:21
    
With this bash command in my code folder: ( find ./ -name '*.cs' -print0 | xargs -0 cat ) | wc -l –  golergka Mar 12 '12 at 9:44
    
right so that is likely to include any generated code e.g. designer.cs - I wouldn't worry about the number of lines you are writing –  jk. Mar 12 '12 at 10:01
    
Generally, yes, but with this particular environment (Unity game engine) it's not the case. –  golergka Mar 12 '12 at 10:07
1  
I try to remove as many lines of code as I reasonably can before adding more. Working on a minimal system is so much more pleasant than the alternative. –  Jon Purdy Mar 12 '12 at 13:16

7 Answers 7

up vote 18 down vote accepted

LOC is probably one of the most abused metrics, and as a result is probably one of the more useless measures of code quality, and an even more useless measurement of programming effort.

Yes, that's a bold statement for me to make, and no, I can't point you to studies proving my point. However, I can state with hard earned experience that when you start worrying about how much code you've written, you're probably worrying about the wrong problems.

You first need to ask yourself what it is you are trying to measure or prove, and whether this proof is merely out of interest, or to support a wider quality improvement and where you need to use this information to get buy-in from your team/management to do something about it.

One of the things that I tend to use LOC for is a bit of a sanity check. If I find myself writing a lot of code, I become more interested in LOC per method, or LOC per class, rather than LOC over all. These measurements might be indicators that you have further refactoring to do if you're feeling a little OCD about how well factored your code should be. Very large classes might need to be refactored into a few smaller classes, and long multi-line methods might need to be broken down into several methods, other classes, or may even indicate some repetition that could be removed. Notice I used the word "might" several times there.

The reality is that LOC provides only a possible indicator, and no real guarantee that your code may need to change. The real question to ask is whether the code behaves as required and as expected. If so, then your next question is whether or not you will be able to maintain the code easily, and whether you will have the time either now or in the future to make changes to working code to reduce your maintenance overheads in the future.

Often, lots of code means that you will have more to maintain later, but sometimes even well-factored code can stretch out to hundreds of lines of code, and yes, you can sometimes find yourself writing hundreds of lines of code in a day. Experience however tells me that if I am sustaining an output of hundreds of lines of new code each day, that often there is a risk that much of the code has been inappropriately cut and paste from somewhere else, and that in itself may indicate problems with duplication and maintenance, but again that is no guarantee, so I tend to rely on what my experience and instincts tell me based on how the tasks at hand were completed.

The best way to avoid the dilemma posed in your question IMHO is to forget about LOC, and refactor ALL of the time. Write your code test first, implement to fail, refactor to pass, then see what may be refactored there and then to improve the code. You'll leave the task knowing that you've double-checked your work already, and you won't be so concerned about second-guessing yourself in the future. Realistically speaking, if you use a test-first approach as I've described, any LOC/day measurement on your completed code will really mean you've written 3-5 times the measured amount, with that effort hidden successfully by your ongoing refactoring efforts.

share|improve this answer
1  
+1 400 lines a day could be an indication of a problem, unfortunately I think the only way to find out is code review, which is difficult on a 1 man team –  jk. Mar 12 '12 at 10:32
    
Thanks for an answer so detailed :) I think it completely covers the subject. –  golergka Mar 12 '12 at 10:50
    
@jk. I believe I address your comment within the context of my answer. When solo, the best way to protect your code quality is to focus on how you write and test your code. A good suite of tests coupled with a continuous refactoring mentality can be as good as a code review in many ways. Note that I am not saying to do without reviews at all, but rather that they should be secondary to ensuring your product meets requirements and has good test coverage, which allows future changes to be made with confidence. My first question during code review is always "Where is the test for this?" :-) –  S.Robins Mar 12 '12 at 11:04
    
+1 for boldness! –  Treb Mar 12 '12 at 11:05
    
+1 Although you cannot point to studies that show that LOC is a bad metric, it is easy to find studies that have run into problems because they used LOC as a metric. –  daramarak Mar 12 '12 at 11:54

If you believe in beautiful functional code, then that should be your only measure

"Does it flow? does it look beautiful?"

share|improve this answer
3  
the only measure? hows about does it work? is it fast enough? –  jk. Mar 12 '12 at 10:34
    
that's why I said functional :) –  Darknight Mar 13 '12 at 10:21

Not at all - some days you are fixing a hard to find bug and only change one line. Other days you're adding new code and write several thousand lines.

Daily LOC doesn't tell you anything except that the tasks for that day could be accomplished with 400 lines of code.

share|improve this answer

You shouldn't be bothered with number of LOC you produce per day.

But you should be bothered :

  • if your code is not tested (if for example, you do not have unit tests)
  • if you start having trouble adding new features or changing implemented features (that means your refactoring wasn't proper)
  • if your experience is not big, and your code is not reviewed (extra pair of eyes is likely to spot problems)
share|improve this answer

LOC is an 'official' measure of productivity, but arguments against its value could be lengthy (An ORM could generate 50,000 lines of code in 3 minutes, however, if the database design is wrong all that code may go to the bin).

I suggest you measure your progress by tracking %completed task vs time vs. % tasks planned to be completed. This is what counts. Customers pay for working code that provides business value not for the LOCs.

Some references about LOC

share|improve this answer
    
but he isn't using LOC as a productivity measure –  jk. Mar 12 '12 at 10:25
    
Yes, but as I said it is not an accurate measure. Same thing when you use "average value of 1,2,100" you get an average but it is biased and not accurate. With LOC, things get worse because each development environment and set of tools could reflect different productivity figures. For example, LOCs can't compare the complexity of the code, only its length. I have amended the original post with 2 references you may want to see. –  Emmad Kareem Mar 12 '12 at 10:44

Some of these answers are missing the point, you are not using LOC as a measure of productivity (if you were then you wouldn't be worrying about being too 'productive'), what you are actually doing is worrying about your code quality because code is the enemy this is a good thing to worry about.

Unfortunately the only way to know about code quality is code review, as you are a one man team this will be tricky, even if you did stop to review your code (and you don't really want to stop, right?) reviewing your own code won't reveal as much as a peer reviewing your code. I'd suggest trying to get someone else to review at least some of your code so you can tell if your 400 LOC/day is churning out gibberish or not. Even an independent review of one days code will help here

share|improve this answer

Are you also measuring the number of code-duplicates?

If the high output is because you have a lot of copy&paste in you code then you should worry.

Reason: in case that there was an error in your copy&paste-source it is hard and error-prone to fix all usages of the copy&paste

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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