back
12 comments
Pretty much every such discussion demands linking:

https://www.folklore.org/Negative_2000_Lines_Of_Code.html

I would definitely agree that early on one writes more lines of code, while later development one spends more time finding where to make a change, and then reviewing the results of the alteration.

Curious how much attention folks pay to this sort of thing --- my current project: https://github.com/WillAdams/gcodepreview is a Literate Program and in its current state just crossed over 1,600 lines of code, but I'm re-working that so that each file will instead be numbered individually.

More lines of code usually indicates more bugs so its not an entirely useless metric. Using it to gauge employee productivity is, since as the linked suggests some of the better programmers are able to remove code, which often reduces the potential for bugs.

I personally find some use it in, if nothing else to identify which files probably need to be refactored as they are too large, or complex. Throw in some cyclomatic complexity and you are getting some useful information out the code counts.

Counting lines of code is one metric though. Another I have seen thrown around is ULOC https://cmcenroe.me/2018/12/14/uloc.html where you count the number of unique lines of code,

    sort -u *.h *.c | wc -l
Again another metric that potentially speaks to the health of a project. I personally wrote about this some time ago when someone asked why I wrote a code counting project https://boyter.org/posts/why-count-lines-of-code/ and I liked the idea of ULOC so much I integrated it into the project as well.

Clearly I am not alone in this though, hence there being so many code counters around (forgive me if I missed yours in the following list) and discussion around it.

    - [SLOCCount](https://www.dwheeler.com/sloccount/) the original sloc counter
    - [cloc](https://github.com/AlDanial/cloc), inspired by SLOCCount; implemented in Perl for portability
    - [gocloc](https://github.com/hhatto/gocloc) a sloc counter in Go inspired by tokei
    - [loc](https://github.com/cgag/loc) rust implementation similar to tokei but often faster
    - [loccount](https://gitlab.com/esr/loccount) Go implementation written and maintained by ESR
    - [ployglot](https://github.com/vmchale/polyglot) ATS sloc counter
    - [tokei](https://github.com/XAMPPRocky/tokei) fast, accurate and written in rust
    - [sloc](https://github.com/flosse/sloc) coffeescript code counter
    - [scc](https://github.com/boyter/scc) my own counter
Incidentally the articles author confused me for a while using standard unix tools to count code, as I had them confused for David Wheeler who wrote the very first code counter that I know of sloccount.
> More lines of code usually indicates more bugs so its not an entirely useless metric.

This is conventional wisdom, but it still feels dubious.

Often I see additional lines of code added to remove a bug, without adding a bug. So comparing the before and after more lines means less bugs.

On the flip side it often indicates more capability, which is more lines, more bugs, more complexity, but also a very unfair comparison.

I am not completely sure what I am getting at here; but, it seems like there are alot of confounding factors.

In my experience it is very common for the additional lines of code added to fix a bug to turn out to introduce a new bug of their own.

The ratio of bugs to lines of code is obviously not constant, but fixing known bugs changes it less than it appears to.

I've seen it stated as, "It is a bit of received computer science wisdom that any program has at least one superfluous line and at least one bug. Apply this rule recursively and you can see that any program can be reduced to a single line with a bug in it." And for proof---http://en.wikipedia.org/wiki/IEFBR14#Implementation
While you are right, in that you add lines to remove bugs, I suspect its still true to say given 2 projects, written in the same language by the same person, on average the one with more lines is more likely to contain more bugs.
Yes, I was going to add another paragraph about more skilled developers using less lines and creating less bug. But this is not true unless the less skilled implementation considers corner cases.
I once was asked to count loc using a tool another team developed, to measure code produced in the last 3 months.

They had imported about a year's worth of crap from a previous repository 2.5 months ago.

I noticed that the loc counter included all commented loc, so I made a legit file of several tens of thousands "loc", checked it in, ran the counter, made the report, was recognized for productivity, and thn reverted the comments.

Productivity, largely, is reducing loc while improving other quality attributes and features...

Next step is to get recognized for simplification and "streamlining" of the codebase, by subsequent reduction.
It can be taken too far, of course, but the amount of bad code and misleading comments in most systems is substantial. On a different company, two of our teams had a competition every Sprint to see who could take out the most code...
Completely agree. It was a little tongue-in-cheek, but actually removing code and the complexity and tech debt associated with it is incredibly valuable.

Especially if more experienced and knowledgeable engineers can remove the code paths that are "in use" but shouldn't be - premature optimizations that can be simplified, redundancies that can be eliminated, features that aren't bringing in value. It's usually an underappreciated job but can lead to greatly improved velocity and significantly less fragility.

I use cloc[0], when I want to count my code (not often. It’s not a metric that really interests me).

It’s generally 50/50, between code (Swift, usually), and comments.

I don’t do the Java “one file for every class” thing, but I still like to keep my files relatively small, if I can.

[0] https://github.com/AlDanial/cloc