Fog Creek Software
Discussion Board




How many lines of code...

How many lines of code are in CityDesk?  I'm guessing 60,000 both VB and C++.

A Great Designer
Sunday, April 25, 2004

Good guess! Around 70,000 in the core CityDesk app. Not that LOC means much.

Joel Spolsky
Fog Creek Software
Sunday, April 25, 2004

As I said to a PM once, "yeah, just 2,000 lines of code, but 2,000 SOLID lines of code."

Leonardo Herrera
Monday, April 26, 2004


The binary code size is the best indication of what you did regardless of how elegant and small the high-level language representation of your code is. The high level code is just an illusion.

grunt
Monday, April 26, 2004

So how do you guys define LOC. Lines of code not including blank lines and comments? Or just "wc -l"? There are so many ways to define LOC, it's hard to know what is meant by it. I typically use sloccount to count lines, and it counts lines the way I described.

sid6581
Monday, April 26, 2004

grunt -
So, you're saying the FPS game available from http://theprodukkt.com/ is not impressive, since it's only 96 kb? Binary size might sometimes look better than LOC, but it really isn't that much better.

Ziktar
Monday, April 26, 2004

> So, you're saying the FPS game available from
> http://theprodukkt.com/ is not impressive, since it's only
> 96 kb?

I said nothing of the sort. I don't know how you picked that up from what I said, but let me clearify myself. All I said was if you are going to count anything, count the bytes of the binary image to tell you how much you wrote since that's what your CPU executes. The same C code compiled using different compilers might yield different code sizes which tells you your "lines of code" measurement really doesn't tell you much. Maybe it is an indicator of some kind for pointy haired bosses.

I personally think lines of code, or even number of bytes of the binary really tells you absolutely nothing.  If you wrote a "hello world" program in visual C++ and the binary is 1MB versus the plain C compiler version is 50KB (or whatever), what exactly does that tell you?!  If you are going to gloat and bloat that you wrote a million lines of code, that's a whole 'nother story.

Did you accomplish what you set out for? That's the real question to answer.

It might matter I guess if you are in a programming competition and the number of lines of code matters, or you are writing code for an embedded system and your resources are limited. Even then, you are still going to look at the size of your binary, not your number of lines of C code.

grunt
Monday, April 26, 2004

>>> So, you're saying the FPS game available from http://theprodukkt.com/ is not impressive, since it's only 96 kb?

I'll say its not impressive.  Not because of code size, but because it doesn't work and makes no attempt to give an error message (or log), even a cryptic one.

Ken Klose
Tuesday, April 27, 2004

Well this game requires video cards supporting DirectX 9. Most non-game developers probably do not have such.
It is impressive in the fact it is quite good looking, it has music and lots of stuff in only 96KB.
The cons are that it takes about 100MB of RAM, it loads in a minute on a very good PC and so on.
So its just an interesting piece of work but not revolutionary as some think.

Boris Yankov
Tuesday, April 27, 2004

The goal of the LineOfCode (LOC) metric is to express the amount of effort it took to create a program, and perhaps to get some idea how hard it would be to maintain it (larger is harder).  AND it can be an approximate measure of a new program to replace the old one.

The size of the binary doesn't reflect effort very much.  It reflects the size of the run-time library you happen to be using, or the amount of code that gets linked in by the compile environment.  You can easily inflate the size of the binary by linking in irrelevant code.

The problem with LOC metrics is as has been stated above -- what do you measure?  How do you count?  If these things are different from language to language, or even from one 'C' style to another, it is hard to compare programs.  But at least you DO have something tangible, that CAN be automatically measured.  There are very few aspects of a program like that (few being less than 50 -- no flames please).

Also, there is a tendency to start measuring programmer productivity in LOC -- 10 LOC/day, 20 LOC/day, etc.  As some have pointed out, you want efficient programs that do what is needed -- not huge bloatware that re-uses huge libraries of code just to get a little function.  'Pure' LOC measurement tends to reward bloatware.

Having said all that, all things being ROUGHLY equal (language, operating system, compiler libraries) you can get some idea of the SCALE of a program by knowing how many LOC it has.  A 1500 LOC program is a large programming project for a school class.  A 5,000 LOC is a reasonable utility function.  10,000 LOC can get you a simple editor.  50,000 +- 20,000 gets you CityDesk.  100,000 to 200,000 -- I don't know, the 747 control program?

There are similar breaks at 500,000, and then 1e6 (a million).  Ada was created to try to handle the complexity of programs 1.5e6 LOC and above.  And I understand Win2000 is around 3e6 LOC of 'C' code.

There is a school of thought that if you have NO IDEA how many LOC are in your application, that this is an indication of innocence, if not incompetence.  Personally, I don't find the LOC metric THAT important -- but it IS true that a 20,000 LOC program is MUCH more easily maintained than a 1.5e6 one.

Common wisdom used to be that a maintenance programmer could maintain 20,000 LOC -- but with current program sizes, that seems too limiting.

AllanL5
Tuesday, April 27, 2004

"-2000 lines of code": http://folklore.org/StoryView.py?project=Macintosh&story=Negative_2000_Lines_Of_Code.txt

anonymous
Tuesday, April 27, 2004

"Personally, I don't find the LOC metric THAT important -- but it IS true that a 20,000 LOC program is MUCH more easily maintained than a 1.5e6 one."

So perhaps LOC should be considered a relative measure rather than an absolute one.

Kyralessa
Wednesday, April 28, 2004

70,000? That's amazing... I worked out all the code I've ever written only numbers in the 30,000's.

How many developers are on CityDesk?

The largest ammount I've done on a single project was 8,000. I was on an open source web server group and we created a functional web server (with GUI) in around 9,000 all up. Keep in mind I'm only talking lines, not LOC... so it's probably even less.

*Still in awe of how much 70,000 is*

Nerd
Friday, April 30, 2004

I don't think 70,000 LOC is that much. A few years ago I single-handedly wrote an Access 2.0 application that was ~20,000 LOC. Some of that code wasn't pretty but it got the job done.

John Topley (www.johntopley.com)
Friday, April 30, 2004

I'm a high-school-student of sorts and I just checked the LOC for my final project. 5800... geez.  But it does contain its ownscripting language.

Marcus
Saturday, May 01, 2004

IMHO LOC is not a very useful measuring method. Too much in it depends of coding style and language.

(For example: in Delphi you have coding macros like 'ifbe',
pressing ALT-J and a complete structure for an 'if then else' appears.)

It's all just a try from an old fashioned money guy syndrom to find at least something to measure a developer, but do you measure a money guy by the amount of excel sheets he produced and mailed around?

Anyway: a more appropriate measurement would be counting the functions and score them (fp analysis). But still, this all lacks of the variety of programmers out there that may know useful libraries, useful patterns and all this. So you still have another value (personal efficiency) that you have to multiply with the fps. Unfortunately both needs experience and empiric data.

tikay
Thursday, May 13, 2004

To count source lines of code : http://ftp.debian.org/debian/pool/main/s/sloccount/sloccount_2.24-1.tar.gz

Alain Tésio
Thursday, June 17, 2004

*  Recent Topics

*  Fog Creek Home