Lines of Code

Why still care about Lines of Code?

Lines of Code (LoC) is a rough metric of the size of software projects. It isn’t regarded as a reliable measurement of team productivity or code complexity. But then again, it does give information worth checking now and then. Especially when you combine it with information about functional changes and code refactoring. So increased LoC increases can be associated with having added new functionality or fixes, while decreases may also be good news: there might have been a code cleanup or even unused features that got removed.

Measuring

I originally maintained an Excel spreadsheet manually with the stats of my Swift project. This meant regularly adding a row with a date and copying in the results of a stand-alone Mac program that counted blank lines, comments and real code. So JSON data files and shell and Python scripts are all out of scope. Which is fair enough: the JSON is “just” data. And the scripts are not too large and non-core anyway.

There were three problems with this: it involved almost daily manual work, Excel files are treated as binaries by git, and that particular free Mac line count program was no longer maintained. So nowadays a script measures LoC data daily using the standard cloc utility. And it extends a .csv file with max one line per day. And that .csv file is displayed on demand as a few graphical charts using a spreadsheet. The spreadsheet loads the .csv file on startup, but doesn’t get updated daily, so git is happy too.

Tour of the data

• The uppermost line, with the labels of releases, shows the total LoC.
• Initially there was only one repository (for iOS app), but nowadays there are four:
  • an iOS app for iPhone and iPad
  • a generator for a (static) HTML website
  • a library used by the above two with shared code to load and access the Data
  • a Project repo with some cross-project stuff (not shown)
• After release v2.7.0, the HTML repo was added. It grew quickly, largely by duplicating (!) existing code from the iOS repo. So for a while there are two repositories: iOS and HTML, with significant overlap.
• The parallel growth of the iOS and HTML repos indicates that most changes ended up in shared code. The associated double maintenance (regularly using `Beyond Compare` to compare and synchronize the repos).
• After release v2.10.0, the Data package (library) was introduced, and you see a drop in size of the iOS and HTML repos. The total LoC also dropped because the shared code went from being counted (and maintained) twice to counting only once. Creation of the Data package was itself significant work because all minor changes between both copies had to be resolved.
• So from this point on there was no double code maintenance, but at price:
  • attention had to be paid to “semantic” versioning
  • attention had to be paid to making Data usable by other future applications
  • adding a new feature meant duplication of documentation if it impacted the Data package (e.g. an extension to the data model), and the other two (more front-end-ish) apps.
• In general, the growth in LoC is now higher. This is not so much due to avoiding double maintenance, but due to the advent of effective AI agents. Which, for example, can generate testing code pretty much on its own. Note that AI Agents also speed up bug fixing code cleanup, and maintenance of the documentation which are hardly visible in LoC data.

Snapshot of LoC at release 3.0.4

As mentioned, the Data package contains the core application: loading data from online data sources (json), merging the data into an in-app database, and exposing the data to clients as an API.

In contrast both “apps” can be seen as interactive user interfaces. Plus, for HTML app, a second user interface: the generation of a static HTML/CSS/scripting code using a package (ignite by Paul Hudson, not counted in the LoC) to abstract the website implementation details.