Dave Laribee

I have no doubt though that if we were crazy enough to rewrite NHibernate we could write it in much less code.  All you need is that 20/20 hindsight from reading the existing code.

I know there's an OSS project going to write a Ruby version of Hibernate.  That would be an interesting comparison.

Any recommendations for a good tool to count lines of code?

And I agree, using a high KLOC count as a source of pride is like showing off how large a garage you need to hold all of your stuff. Unless you've managed to fill it with great, meaningful stuff, it's pretty embarrassing.

i agree.  i always tell my coworkers that code is a liability, not an asset. as opposed to features, which are assets.  so the higher feature-to-code ratio we can get, the better.

the more code you have, the higher chance that more of it isn't going to work right.  one of the reasons that refactoring and being DRY are important.

You bring up an interesting issue when you say that "...but when a system tips 5-10,000? To me that's a good time to start looking for ways to partition into separate modules, assemblies, packages whatnot".

Aren't you assuming there that whoever brought up their 1 million LOC system, they meant "Our unmaintainable, monolithic, unchangable System has 1 million lines of code!", versus saying "Our System has 1 million lines of of well organized, properly modularized, maintainable code"?

Granted, I don't know many cases of the latter :), but just  pointed out that a large LOC count for a *complex* application doesn't need to necessarily mean it's a big pile of mud. After all, complex applications will be naturally gather a certain level of complexity (with a higher LOC being one sideeffect).

IOW, a certain LOC number is meaningless unless it is attached to a boundary (system, application, module, assembly, whatever), and can be considered slightly useful (broadly speaking) only in relation to that boundary

Person1: "My last project had 1 million LoC!"

Person2: "Then you learnt about 'for' statements"

That 400,000 lines of code for NHibernate sounds suspicious, especially when you consider that it's supposedly %68 XML...

Koders.com lists it at 78,000 lines of code www.koders.com/info.aspx

But they unfortunately don't have RoR for comparison.

Another thing to consider is that C# has a lot of mostly empty lines ( single braces for instance).  So yeah, it's like comparing golf scores, but you might be looking at PGA tournimant, a family at a minigolf course, and some college kids playing frisbee-golf.

@Dave: Absolutely, I agree. just mentioning that the boundary is pretty important :)

Great point, less is better!  You bring up a great point that sometimes developers miss is that the more code you write, the more you maintain.  Now, if you want to maintain code for the rest of your career, go for it.  I sure don't want to.

Line count

Well, LOC as a indicator in general is an approximation, but attractive since it is easy to get an exact measure. The issue of LOC as productivity is an old one, but I think most agree that it is suboptimal.

("relative meaningless of KLOCs as a measure of productivity:")

Humans have narrow limits to handling information, and thus size becomes an issue of complexity. In my view, abstraction deals with this by grouping, etc. At the same time, creating that abstraction will add more lines of code. So, I would think that the opposite is true - all other things being equal.

Note the condition that I added. Comparing apple LOCs to oranges LOCs isn't really helpful. Nevertheless, "less is more" may not be true for LOC.

An example: Lets say we have two systems built using the same technologies (language, say your favorite, etc) and providing the same services. Both are basically well developed, having eliminated duplication. (This incidentally sets both ahead of most existing software today.) The first is not very well structured however, perhaps leaning more towards procedural practices but more importantly not focused on readability and maintainability. The second project is so focused, however. I would think that the second project would have a higher LOC.

Another concrete example: Long one liners. 1 LOC. Usually not readable. Making a long one liner readable usually makes me extract several local variables and maybe even a method. That will add severals LOC, but increase readability and thus maintainability.

So, in the former example, the first project is the ball of mud.

Make sense?

PS

Or, on a less serious note; you write: "One of the many appealing things about Ruby culture is that the LOC measure is a sort of golf score: lower is better."

*Eww*, perl or maybe ioccc anyone? Ruby - a disgusting little language with a culture that also sucks! Muuhhahahahah! (this is great fodder to tease my mac-lugging collegues with)

;-)