Thread: 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?

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

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.