Fog Creek Software
Discussion Board




Ranking projects by LOC

just curious as to what codesize would people classify large and medium projects in an OO language.
At work I have done around 10K LOC projects (around 20-30 classes), with me being the only dev guy on that particular part.Would you classify it as small or medium size?

anon
Monday, February 24, 2003

As a regular viewer of ER, I always rank my projects by LOC.
If I lose consciousness more than three or four times during a project then it is definitely large!

David Clayworth
Monday, February 24, 2003

I have found (guesstimate),

For any given person:

If all the sources are in text and zipped up
and the programming language is equivalent
to a high level scripting language.

Anything under 750 kilobytes compressed:
Small (most small business projects fits in
this one)
Anything under 1750 kilobytes compressed:
Medium (a handful for a full time coder)

Anything over 1750 kilobytes compressed:
Medium Large (takes a team almost for sure,
only the rare person can handle this by
himself)
Variables to consider includes modularity, a
loosely coupled architecture is easier to
manage. Scheduling affects things.
Complexity of the domain being solved by
software matters a lot too. How experienced
the programmer is matters. But these kinds
of issues gets into software engineering.

Er.. why do you ask?

-- David

Li-fan Chen
Monday, February 24, 2003

(Borrowd from how a former professor who used to grade my papers).

Weigh The Code.

If the code weighs < than 1 Oz. Small
=>1 Oz. but <= 3 Oz. Medium
>3 Oz. Large

Daniel Shchyokin
Monday, February 24, 2003

To me, this depends on the type of application being developed.

If someone writes 10,000 lines of code to implement a calculator, that's a big project.  OTOH, if it's an operating system, that's small.

In general...well, in general, it doesn't matter.  It's 10,000 lines of code.  Comparing its size relative to other projects too quickly devolves into posturing.

("My project's bigger than your project!"  "Oh yeah?!")

Brent P. Newhall
Monday, February 24, 2003

Should there be a difference in size between OO and non-OO code?

Here's some stats:

4 coders, 2 years

system complexity: high
coder experience: medium to high

175K lines of C
1.6M zipped

xyz
Monday, February 24, 2003

Do LOC counts include blank lines and comments?

Sorry
Monday, February 24, 2003

What about comments?

Neil E
Monday, February 24, 2003

From what I understand, a true LOC count does not include blank lines or comment lines.

Brent P. Newhall
Monday, February 24, 2003

Depends on language and libraries used. The fact that it is OO is pretty much irrelevant. For example, both Java and Ruby are OO languages, but Ruby gives 10 times more compact (and readable) code.

raindog
Monday, February 24, 2003

P.S. Just as an example.

Problem: reverse a file.

Java solution (39 lines of code):

// $Id: reversefile.java,v 1.4 2001/08/15 16:19:17 doug Exp $
// http://www.bagley.org/~doug/shootout/
// from Stephen Darnell

import java.io.*;

public class reversefile {
    final static int BUFF_SIZE = 4096;

    public static void main( String[] args ) {
    InputStream in = System.in;

    byte[] buff = new byte[BUFF_SIZE];
    byte[] obuff = new byte[BUFF_SIZE];

    try {
        int pos = 0;
        for (int n ; (n = in.read(buff, pos, BUFF_SIZE)) > 0 ;) {
        pos += n;
        if ((pos + BUFF_SIZE) > buff.length) {
            byte[] new_buff = new byte[buff.length << 1];
            System.arraycopy(buff, 0, new_buff, 0, buff.length);
            buff = new_buff;
        }
        }

        int opos = 0;

        for (int p = --pos ; ;) {
        --p;
        if (p < 0 || buff[p] == '\n') {
            for( int bp = p ; ++bp <= pos ; ) {
            obuff[opos] = buff[bp];
            if (++opos >= BUFF_SIZE) {
                System.out.write(obuff, 0, opos);
                opos = 0;
            }
            }
            pos = p;

            if (p < 0)
            break;
        }
        }

        System.out.write(obuff, 0, opos);
    }
    catch(IOException ex) {
    }
    }
}



Ruby solution (1 line of code):

#!/usr/local/bin/ruby
# -*- mode: ruby -*-
# $Id: reversefile.ruby,v 1.2 2000/11/27 03:39:26 doug Exp $
# http://www.bagley.org/~doug/shootout/

print STDIN.readlines().reverse()

raindog
Monday, February 24, 2003

raindog, no offense, but your reverse a file example has all to do with libraries & not actual languages.

GiorgioG
Monday, February 24, 2003

oops, I should read all the posts! sorry raindog ;-)

raindog wrote:
<<
Depends on language and libraries used
>>

GiorgioG
Monday, February 24, 2003

That is quite possibly the most brain-dead version of reverse-a-file program in Java I've ever seen.  This is slightly better:

import java.util.*;
import java.io.*;

public class ReverseFile
{
  public static void main(String argv[]) throws IOException
  {
      BufferedReader inf = new BufferedReader
            (new InputStreamReader(System.in));
      String s;
      List l = new ArrayList();

      while ((s = inf.readLine()) != null)
      {
        l.add(s);
      }

      for (int i = l.size() - 1; i >= 0; i--)
      {
        System.out.println(l.get(i));
      }
  }
}

Alyosha`
Monday, February 24, 2003

Ultimately, every project is just a one liner.

It's the length of the line that varies.

Realist
Monday, February 24, 2003

Alyosha, I took the code above from the Great Language Shootout page (http://www.bagley.org/~doug/shootout/), where the languages were compared performance-wise. Obviously, every language code was tweaked (by language experts) to take too much memory and run faster. This is probably why it looks so ugly. Just my guess.

raindog
Monday, February 24, 2003

Sorry, raindog, I didn't mean to sound disparaging of you because the Java code that you posted -- I knew already that you did not write it.  But I must say that whoever wrote that steaming pile of fecal material cannot be, by any means, a "language expert".  He seems ignorant of the ArrayList (or even Vector!) class, and chose to hard-code a fixed-sized buffer.  He also seems ignorant of BufferedReader.readLine method, which I can understand, because it's hard to find that method in the documentation unless someone tells you about it.  His program also assumes that eol is "\n" and not "\r\n", which is a very poor assumption.

Besides, the context of this discussion was about lines-of-code and ease of programming.  You mentioned that Ruby was much more compact and readable than Java and gave this as an example.  I wanted to point out that it doesn't take a 39-line monstrosity of a program to reverse a file in Java, it can be done in 11 easily-readable lines.  If you wanted to talk about speed and performance, point out that Ruby took about twice as long to execute in this (admittedly poor) benchmark.

Who knows, maybe he uglified his program purely for performance reasons.  I can't imagine he got any performance increase, but who knows ... maybe on his system, maybe the phase of the moon ... it went faster.  I know that if I had a programmer working for me that churned out crap like this and defended it with "but it's 2% faster", I'd sack him immediately ... God gave us class libraries for a reason ...

Alyosha`
Monday, February 24, 2003

Actually I have to eat my words, their version was significantly faster (15ms vs, 115 ms) since it read 4096 bytes at a time rather than a line at a time.  I suppose if performance was an issue, the other code would win hands-down.  Also it doesn't matter if EOL is \n or \r\n, \n is always at the end of the line.  ;-)

It's still ugly as hell though, and not the easiest way to reverse a file in Java.

Alyosha`
Monday, February 24, 2003

Alyosha, I was not going to start a language war here :) No, my point was simply to show that LOCs don't tell much about project's complexity. Note, that the 1-line Ruby version above is the most efficient Ruby version. And, in this context, it's quite irrelevant how it compares to Java performance-wise.

raindog
Monday, February 24, 2003

To get more on topic here...

In my opinion LOC is more about complexity than size. Obviously a larger project will tend to have a higher LOC than a smaller, but I ask: Where exact lies the largerness? Is it in the amount of code or in domain difficulties?

I am now working VB code produced during the last 6-7 years, not a scientific measure, but a file search on everything which can contain VB code gave me 1031 files and 20MB of source code. In my opinion the project is not large, the domain can be hard to understand, but not difficult. A little complex, prehaps, but most of all I think numerous coders and time pressures have made the code unbelievable more obfuscated, eerh, complex.

The largest class has 1.4MB of code and measures 30kloc! Yes, I did say class, not project.

Thomas Eyde
Tuesday, February 25, 2003

I want to second that "Why do you want to know" question. What will be the concequences of it being declared a "large" or a "small" project?
What is the real question here?

Just me (Sir to you)
Tuesday, February 25, 2003

just out of curiosity

anon
Tuesday, February 25, 2003

KLOC's are a very dangerous parameter to measure a software projects size, complexity or worse, coding productivity.

A brainless coder might just duplicate his code a couple of times and have a huge project in KLOC's, while the top hacker might actually reduce code size over time, because he is constantly restructuring and cleaning up code.

In short: forget about KLOC's.

IIRC Microsoft and IBM once went into a fight because they had agreed to reward OS/2 development based on KLOC's. Steve Balmer ranted about that really bad decision in Bob Cringely's Triumph of the Nerds.

Jan Derk
Tuesday, February 25, 2003

Then I am afraid any answer beyond "whatever you fancy" is meaningless.

Just me (Sir to you)
Tuesday, February 25, 2003

Someone (Dijkstra?) made the astute comment that every line of code is a liability, not an asset. In other words, KLoC won't tell you how valuable a project is, but it may indicate how much it will cost to maintain.

To get back on topic, my belief is that project size should be measured by the amount of organization required to complete it in a reasonable amount of time.

To wit, any one developer should be able to finish a small project in a few weeks. I ballpark the upper bound at about 10 KLoC.

Large, under this definition, is very dependent on the size of the development team. A large project for a small consulting shop will be considerably smaller than a large project for, say, Microsoft. In any case, I would guess that anything over 1 MLoC requires substantial organization to complete.

Devil's Advocate
Tuesday, February 25, 2003

[Someone (Dijkstra?) made the astute comment that every line of code is a liability, not an asset.]

I've read the same quote. Does anybody here know from what essay/article/book it came? It sounds like an interesting read.

I tried a few google searches, but had no luck finding the source.

Ken Dyck
Tuesday, February 25, 2003

I am probably missourcing.. but it might be the Mythical Man Month

Li-fan Chen
Wednesday, February 26, 2003

The goal I guess is to prevent code from bloating.. but actually have successive versions of the software shrink :-)

This ofcourse would be very difficult unless you architect your software
in a loosely coupled manner like the standard executables that come with UNIX.. they stay small because they do one thing and that one thing well.. and use STDIO redirection to reuse the power of other utilities in the system.

Li-fan Chen
Wednesday, February 26, 2003

*  Recent Topics

*  Fog Creek Home