SLOCCount also estimates development time in person-years as well as the number of developers and the cost to develop. One can override the defaults and specify parameters such as costs per person, overhead and effort to make it match to your development model.
Of course, like all tools that produce metrics it can be abused, for example using it as a meaningless metric of programmer productivity. Counting lines of code does not really measure project complexity, a vexing bug that took 2 days to figure out and resulted in a 1 line fix is obviously more expensive than a poorly written 500 line function that introduces a no new noticeable functionality. As a rule of thumb, SLOCCount is a useful tool to get an idea of the size of a project and some idea of the cost to develop it. There are of course more complex ways to examine project source code, such as cyclomatic complexity metrics, and there are specific tools such as Panopticode that do this.
As a small exercise, I gave SLOCCount the task of counting the lines of code in the Linux kernel from version 2.6.12 to 3.6 and used the default settings to produce an estimated cost to develop each version.
It is interesting to see that the rate of code being added seemed to increase around the 2.6.28 release. So what about the estimated cost to develop?..
This is of course pure conjecture. The total lines of code does not consider the code of some patches that remove code and assumes that the cost is directly related to lines of code. Also, code complexity makes some lines of code far more expensive to develop than others. It is interesting to see that each release is adding an average of 184,000 lines of code per release which SLOCCount estimates to cost about $8.14 million dollars or ~44.24 dollars per line of code; not sure how realistic that really is.
Anyhow, SLOCCount is easy to use and provides some very useful rule-of-thumb analysis on project size and costs.