📅 Posted 2018-10-22
My friend @boyter has written a lot about counting lines of code, so I thought I’d have a stab at running his fantastically fast source code counter “Sloc, Cloc and Code” scc
over the Koi CMS codebase to see what it thinks.
Firstly, if you haven’t thought about counting lines of code or want to know more, Ben has written a lot about this, so check out these links:
- https://boyter.org/posts/sloc-cloc-code/
- https://boyter.org/posts/why-count-lines-of-code/
- https://boyter.org/posts/sloc-cloc-code-revisited/
- https://boyter.org/posts/sloc-cloc-code-performance/
And if you’re after the scc
source code or builds, swing over here:
Oh yes, and I removed pretty much all bits of code I didn’t write (node_modules and the like) to make sure the results aren’t skewed by things I didn’t write. So this is all based on code that was written specifically for Koi CMS. The overall investment from open source dependencies would be quite staggering by themselves.
Onwards to the results
scc .
-------------------------------------------------------------------------------
Language Files Lines Code Comments Blanks Complexity
-------------------------------------------------------------------------------
JavaScript 81 10797 9471 727 599 1558
HTML 38 4092 4062 28 2 0
JSON 9 20521 20521 0 0 0
Plain Text 5 89 67 0 22 0
Batch 2 10 10 0 0 0
Markdown 2 331 179 0 152 0
YAML 1 422 422 0 0 0
Shell 1 1 1 0 0 0
gitignore 1 61 26 18 17 0
CSS 1 155 117 2 36 0
License 1 21 17 0 4 0
-------------------------------------------------------------------------------
Total 142 36500 34893 775 832 1558
-------------------------------------------------------------------------------
Estimated Cost to Develop $1,125,824
Estimated Schedule Effort 16.049059 months
Estimated People Required 8.309514
-------------------------------------------------------------------------------
This is pretty fascinating, not only because it took me about a year to develop Koi CMS, but also because of the liberal use of JavaScript in this project.
The mass of JS is roughly split 50:50 between all of the Node JS Lambda functions which power the API, but also the frontend content editor, known as “Ed”.
The large amount of JSON is explained by some enormous AWS API Gateway Swagger definition files, which are over 200kb each! Thankfully I did not have to write these files by hand, but I did set them up manually in the AWS Console. Probably not the best use of time, but it’s one of those things that grows slowly and when you stand back and look at it… it’s a bit of a monster.
Here’s what I’m talking about in the API (this is at 30% zoom):
Diving a bit deeper
But back to the counting lines of code. I’d like to dive into more detail.
Adding the -files
option reveals a bit more detail about where all of the lines go and it’s not surprising.
scc -files .
-------------------------------------------------------------------------------
Language Files Lines Code Comments Blanks Complexity
-------------------------------------------------------------------------------
JavaScript 81 10797 9471 727 599 1558
-------------------------------------------------------------------------------
koipond.io-ed\js\koipond.js 4612 4066 230 316 447
~d.io-lambda\app\libs\utils.js 835 705 75 55 172
~pond.io-lambda\app\libs\s3.js 345 311 25 9 53
~d.io-lambda\app\libs\email.js 240 218 9 13 18
~pond.io-lambda\app\Publish.js 196 110 82 4 15
<snip>
For JS, it’s the main file which powers all of the content editor, closely followed by shared libraries of code. The “Publish” function in itself is quite complex, even though it delegates the real website generation off to Hugo, but setting up the environment with the files in the right place and pushing the files back out to S3 again isn’t trivial.
For HTML, it’s the page editor which has the richest functionality and therefore the most buttons and widgets of all components.
For JSON, it’s the API definitions.
I did come across one minor bug: turns out the order of options matters a lot for scc
, so:
scc -v .
works finescc . -v
does not work and it just ignores the verbose flag as if you didn’t specify it
Performance Observations
It’s fast. Like, real fast. It appears to take longer to print and refresh the screen than read the files and calculate the lines of code. I didn’t try any other program for comparison. Koi CMS is not exactly the most complex of projects but the point was to give it a spin and see what happens for interest sake.
Wrapping up
scc
is fun. Through using COCOMO estimation, I apparently spent a million dollars on the system. It’s probably about right, if I did really hire a bunch of engineers for 16 months to build the system. But I didn’t, and that’s probably evidenced in some of the rough corners of the product. That’s ok, there’s always a roadmap to follow.
Try it for yourself at GitHub.
Like this post? Subscribe to my RSS Feed or Buy me a coffee
Comments are closed