Like Tree5Likes
  • 2 Post By phantomotap
  • 3 Post By grumpy

Coding Time per LOC and Debug time per LOC

This is a discussion on Coding Time per LOC and Debug time per LOC within the C++ Programming forums, part of the General Programming Boards category; Hi all, I just spent 3 hours writing and debugging 37 lines of code. Is this normal or am I ...

  1. #1
    Registered User Vespasian's Avatar
    Join Date
    Aug 2011
    Posts
    181

    Coding Time per LOC and Debug time per LOC

    Hi all,

    I just spent 3 hours writing and debugging 37 lines of code. Is this normal or am I "below average" in coding abilities. I come from a C background and decided to write C++ code that I finally got right as shown below for the specific example:
    Code:
    #include <iostream>
    #include <fstream>
    #include <string>
    
    #define SPACE_SEARCH 10
    
    using namespace std;
    
    void convertfile ()
    {
        string line;
        ifstream oldfile;
        ofstream newfile;
    
        oldfile.open ("C:\\Before.txt");
        newfile.open("C:\\After.txt");
    
        for (int i = 0; !oldfile.eof(); i++){
            getline(oldfile, line);
            for (int j = 0; j <= SPACE_SEARCH; j++){
                if(line[j] == ' '){
                   line.erase(0,j+1);
                   break;
                }
            }
            newfile << line <<"\n";
        }
        oldfile.close();
        newfile.close();
    }
    
    int main()
    {
        convertfile();
        return 0;
    }
    As you may see, nothing spectacularly fancy, just a program that takes a text file source code including line numbers, example:

    Code:
    001 #ifndef FINDDIALOG_H
    002 #define FINDDIALOG_H
    003 #include <QDialog>
    004 class QCheckBox;
    005 class QLabel;
    006 class QLineEdit;
    007 class QPushButton;
    and output into a text file, in the same directory, a source file without code lines:

    Code:
    #ifndef FINDDIALOG_H
    #define FINDDIALOG_H
    #include <QDialog>
    class QCheckBox;
    class QLabel;
    class QLineEdit;
    class QPushButton;
    I think it was more the learning along the way that consumed atleast 75% of my time for this specific case. But then again, I read that programming always entails learning along the way and so its somehow no excuse for the long time taken in this specific case.

    So as a matter of interest, what pace do all of you operate on, on average? i.e. LOC/day, Debugs per day or any other indicator of productivity? And is the above case a very poor show of productivity?

  2. #2
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,183
    O_o

    Would your time be better if your implementation required more lines assuming it still worked exactly as it does?

    Would your time be worse if you had fewer lines assuming it still worked exactly as it does?

    There are some bugs in your code; it will take time to fix those bugs. Is the time spent fixing those bugs going to damage your current time? You are going to have to rewrite part of what you have to fix one problem I see, if it takes you three hours to write that version that doesn't have those bugs also and you only have 4-5 lines more than you have now were you more productive than you were when you wrote this code?

    *shrug*

    My average for the last two weeks probably works out to about -3 lines per day.

    Happily, "LOC" and similar is a meaningless metric forwarded by people who don't know any better.

    Don't believe me?

    My comment above about having a "LOC" of -3 per day really is pretty near the mark. The pull from my source says 14,516 bytes versus 12,810 bytes measures today. (I should mention I use spaces instead of tabs for indentation.)

    I spent the last two weeks redesigning a crucial part of an engine. It now handles about 275,000 (500,000 baked) expansions per minute per real thread instead of just 150,000 (250,000 baked).

    If we were going by "LOC" my work would be worthless as I actually have less code than I started.

    If you find you need to measure your productivity, do it by goals. Feel free to set those goals however you like so long as they are meaningful.

    You might, for example, have said "get the implementation for the `convertfile' interface written" in four hours. You would have met your goal as well as worked heavily on the quality of said implementation.

    With such a goal as that, it doesn't matter how many lines of code you write or how many bugs you are perceived to eliminate.

    Soma
    stahta01 and Elkvis like this.

  3. #3
    Registered User
    Join Date
    Jun 2005
    Posts
    6,208
    What you're doing is a actually significantly faster than professional coding. I wouldn't take that as a sign of great prowess though.

    Beginners (particularly) always crank out code faster than professionals, because they address smaller and simpler problems (I can't remember the last time that a professional wrote a complete program for the sole purpose of removing spaces from the first ten characters in each line of a file), their problems are better defined (e.g. a teacher often does the work to define the objective, and make sure it is aligned with what is currently being taught), and because beginners rarely document their work.

    Producing a design from ambiguous requirements, production of design documentation, user guides, etc are all part of professional development. Beginners don't do those things, so can do things faster. The professionals who avoid doing those things, and portray themselves as highly productive are - in reality - often just offloading significant effort onto someone else to do the other aspects they have left out. For safety critical development, for example, regulators require design documentation and evidence that the code actually implements the design - just dropping a heap of code on the table is not enough.


    Studies have shown that the average productivity of a professional programmer in a team environment is about 10 LOC per day. This describes the code that finds its way into the final product, and it does account for the deletion of code from the final product (code which initially found its way into a product, but needed to be removed later) - removal of code subtracts from the LOC figure. It doesn't usually include the learning samples that a developer hacks together on the side to test an idea before committing code into the final product.



    Personally, I think LOC is a disgustingly lousy measure of productivity. In part because it is a figure that can be artificially inflated by a developer not doing other essential things (such as not documenting), and can be artificially deflated by techniques that improve productivity (e.g. effective code reuse, for example, contributes to a reduction of LOC measures, because rewriting functionality from scratch creates more LOC than does reusing code from a good quality library). Measures based on quality of code, evidence of number of features actually delivered, number of independently formulated test cases that are passed, etc are better - albeit harder to assess.
    stahta01, Salem and antred like this.
    Right 98% of the time, and don't care about the other 3%.

  4. #4
    Your imaginary friend
    Join Date
    Jan 2010
    Location
    Canada
    Posts
    76
    Still being a beginner myself, I wouldn't say it's bad.

    If this is your first time working with files, then you had a super productive day, if it's not the first time you still completed the work you needed to.
    LOC is rather stupid, never even thought of checking productivity myself but if you go by pure filesize/lines then you can modify it, and cheat the engine very easily.

    It's true though that programming is a thing where you are constantly learning, but at one point when you have done the same thing enough times, you will do it much faster. If you are learning from scratch then it will automatically take longer.

    It's like asking an author to write a five page shortstory. Ask the same of a child, now. Of course the author will do it much faster, with less errors n his grammar and spelling, but they could produce the same basic story. One could describe a castle with twelve lines, while the other uses simply two. I hope you get where I am going with this, for I am leaving the sake of explaining to your own mind.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. [HELP] Code to Convert Army Time to Normal Time?
    By Kipper DeVera in forum C++ Programming
    Replies: 9
    Last Post: 08-21-2011, 11:50 PM
  2. Replies: 23
    Last Post: 05-22-2011, 11:20 PM
  3. Replies: 7
    Last Post: 11-21-2009, 12:02 AM
  4. Running Debug in Real Time, possible?
    By pliang in forum Game Programming
    Replies: 4
    Last Post: 04-21-2005, 07:29 AM
  5. coding time
    By iain in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 08-17-2001, 09:22 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21