Consider disabling comoco and size by default

[arp242]

It seems to be that the "Comoco" reports are rarely to never useful – certainly the defaults aren't useful. For example, last evening and this evening I spent a bit of time on a small ls-like program. scc reports:

───────────────────────────────────────────────────────────────────────────────
Language                 Files     Lines   Blanks  Comments     Code Complexity
───────────────────────────────────────────────────────────────────────────────
Go                          10      1374      114       199     1061        264
License                      1        20        4         0       16          0
Markdown                     1        94       23         0       71          0
YAML                         1         1        0         0        1          0
───────────────────────────────────────────────────────────────────────────────
Total                       13      1489      141       199     1149        264
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $31,255
Estimated Schedule Effort (organic) 3.69 months
Estimated People Required (organic) 0.75
───────────────────────────────────────────────────────────────────────────────
Processed 40917 bytes, 0.041 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────

I did 3 half a half months of work worth $31k in two evenings? 10x programmers watch out, here I come!

These numbers are just completely off; not "rough estimate" off, but "completely bonkers alternative universe" off. This is true for all projects I've seen.

The "processed n bytes" is perhaps a bit more useful, but I think most people just want line counts, and don't really care about it. It's just a few more lines of "wasted" space in my terminal.

The -no-cocomo and -no-size flags can be turned into no-ops, and a new -cocomo and -size flag can be added. So then the default would be:

───────────────────────────────────────────────────────────────────────────────
Language                 Files     Lines   Blanks  Comments     Code Complexity
───────────────────────────────────────────────────────────────────────────────
Go                          10      1374      114       199     1061        264
License                      1        20        4         0       16          0
Markdown                     1        94       23         0       71          0
YAML                         1         1        0         0        1          0
───────────────────────────────────────────────────────────────────────────────
Total                       13      1489      141       199     1149        264
───────────────────────────────────────────────────────────────────────────────

I'll send a patch if you approve of this, or if you don't you can close it – that's okay too.

[boyter]

So... oddly enough the reason it was included initially was because it was a function people liked about sloccount which was missing in every other tool.

The reason it remains is because it helps with the spread of scc itself. The estimation has its viral moments on social media, which helps drive adoption. Consider it developer marketing.

That said it can help to know what its counting. It works best when used on larger projects, and isnt just an estimate of the work you did, it also includes training costs, the hardware costs and other factors in addition to the developers salary. The time has a similar thing in there. For smaller projects IE something you did in your few evenings, it is indeed way off the mark.

Id be happy to swap it out for another model though if you know of one and can point me at an implementation of it. I had considered adding in COCOMO2 but was unable to find enough details to actually implement it.