As a code base ages it is natural for its SLOC count to increase or, at best, not move as more functionality is added. This is inevitable but also perfectly fine. If we look at the Gridcoin source tree we can see that even though a lot of things have been added, much of the obsolete has been removed which is why the graph is sort of flat up until The Great Code Removal of 2017:
Those who have followed me on IRC or Slack know that I have an almost sickly obsession with code removal. To me, removing dead, or zombie code is the easiest and most relaxing form of refactoring and offers instant gratification with almost zero risk involved. Occasionally the worst thing that can happen happens; you removed code which is used on another platform and you just add it back. This removal has become a part of my daily routine and is something I do when I'm too tired to think but want to do something.
Code complexity
Every line added to a program introduces complexity but in return you gain functionality. Inversly, every line removed removes the functionality but also reduces complexity, right? It seems pretty straight forward but there is an exception to this though. I would argue that removing all references to a piece of code while keeping the piece of code itself (thus making it a zombie) actually increases the overall complexity of the code base in addition to what the piece of code adds in itself. What used to be a useful member of society is now an ambiguous blob of text. The piece of code now imposes questions to the reader.
- Why is this still here if nobody uses it?
- Should I use this or is there something wrong with it?
- Is the intention to use it later on?
- Who the hell authorized this?
In order to understand why the code is unused you suddenly have to see a much greater picture and be aware of historical decisions. You have to move towards becoming an expert when you really shouldn't have to.
Another thing to keep in mind is the complexity perspective from a new viewer. The more code you have to absorb and consider, the harder it becomes to understand the flow.
Build times?
This is probably the most obvious reason for code removal.
More code = more lines to compile = longer build times.
Since we have undergone so many removals you would expect to see an equal drop in build times. The reality is that the sheer amount of source in c/cpp files actually has less of an increase on build times than you might think. Sure, a lot of code increases the times, but a small reduction doesn't do much which becomes apparent when you add it to the chart:
.png)
Compilers are usually quite fast so removing 20 lines of code is not going to have a noticable impact. The drop in 3.5.8.9 comes from improved header discipline which does much, much more for the build speeds. Before that all versions compiled with a difference of +/- 1 second.
Maintenance
It may sound counter intuitive but unused code has to be maintained almost as much as live code, except for refactoring for performance or readability. Every time you do a refactoring task which involves the dead code you have to make sure it still compiles, that its unit tests are working and that its documentation is still valid. If the code you refactor does not add value you are doing the work for nothing.
Conclusions
I am not alone in this crusade. ifoggz and Tomáš Brada have removed both unused RPC commands and a slew of obsolete Proof-of-Work code. The result of that is the reason for the massive code dip in the development branch. As a result we now have ~5000 fewer lines. That is code we never have to see again, never have to consider and never have to explain. It's a great time to be alive.
Great work guys!
I did know you where removing code and reducing the overall zombie code, but that the build times where that drastically decreased in a previous bild I did not know.
You keep it simple, precise and don't wander of from the topic of the post, which is code refactoring and build times. And some very descriptive and relevant graphs, love it.
Just what I expect from a post from a developer 👍
Looking forward to more exiting topics from the inside 🤓
Thanks :D It's hard to know if you're stating the obvious but hopefully some things were news.
One mans common thing is another mans news? 😋
Understandable when your involved in it and think its just the most obvious and common.
Zombie code (e.g. unreferenced code) should impact compile time marginally since it will be the first to be optimized away. The most important reason to remove is what I refer to as "Write code for people, not for computers". Readability, being able to follow/understanding the code is very important. Header discipline has often a great influence on compile time, certainly when those headers contain implementation.
Glad you were able to do some massive refactoring. Maintaining a good code base is often two steps forward, one step back.
You got me interested to take a look at it. (maybe involved if in need of support)
Absolutely! Join us on Slack in #development. There is lots of activity these days and we need all the help we can get.
You are doing an excellent job @ravonn cleaning up the code base. There's nothing worse than wading through spaghetti, especially if it's a bit rotten :-)
Looking forward to the next release with the V8 staking kernel and TheCharalatans depends build system.
This type of work is just as vital as adding new features. Right up there with adding more unit tests and making sure the code coverage is up there. The outside world never sees this type of work, but I assure you it should be applauded and encouraged as much as possible. Well done, team!
This is a really interesting peek behind the scenes. Thanks for this
Really great work you are doing there! :)
One big reason why I always remove unused/old code is that others might find it and build up on it or (maybe even worse) use the underlying patterns. The old code might be written in an old pattern that you are currently trying to move away from. But if people see it all over the place they might adapt to it. I have seen that a lot, so I am totally with you when it comes to removing legacy code :)
I really like your post, I will wait for the next posting