Code Refactoring & Reworking in Waterbear

Refactoring code is an important step in the development process, but can get pretty complicated when working on an open source project. When the contributors on a project are constantly changing, it is common for code to stay in its initial state for a long time. As the code base continues to grow and evolve, this old code can become outdated. This is when refactoring comes into play. Code refactoring can be many things, such as removing duplicate code, improving efficiency of code, reducing bloated functions and adding documentation by making code more readable.

Sometimes refactoring code is not enough to deal with outdated code. Typically refactoring code does not change the functionality of the program, but as any developer can tell you, a project’s requirements will always change over time, therefore the code will need to be reworked! In this case “reworking” is just a broader term for refactoring. Refactoring is focused on improving the quality of the code itself, while keeping the functionality the same. Reworking can be anything from completely rewriting code to taking existing code and tweaking it to get a new desired functionality.

Refactoring and reworking code are both essential to keeping a good code base and having a functioning program, but are used at different times. For example, in an open source project such as Waterbear, where save for the creator Dethe, the main contributors are frequently changing, it is very easy for duplicate code to be produced. Sometimes it may be because the code base is large and a new contributor doesn’t know where to find a function they need, so they write one instead. Other times it can simply be because they were in a rush and wanted slightly different functionality from an existing implementation so they wrote a new, very similar function. In either case, the duplicate code can be refactored so that there is only one version of the function that encompasses all the previous functions’ abilities. But be careful, sometimes this can result in a bloated function! A bloated function is a function that is very long and does many things. Once again this can be solved by refactoring! The bloated function can be separated into multiple functions, each with a specific task, that can then be called to perform the desired functionality. With this sort of refactoring, there is no change in functionality but the code has been changed to be more organized and easier to use and maintain in the future!

For an example of reworking code I will give an example of a recent change to the Waterbear language. As a new contributor to the project I was making an example with Waterbear to try and get familiar with it. As I was doing so, I can across some blocks that I could not figure out how to use, the Path blocks. One of the many nice things about open source projects is that there are constantly new, fresh eyes looking at the program. As new contributors are added to a project they are able to see issues in the code or program, that the other developers may have never noticed or never got around to fixing. Sometimes when developers are too close to a project they fail to see when the software doesn’t make sense for new users. As was the case with the Path blocks. To the more seasoned developers, the Path blocks were easy enough to use so they’re refactorization had never been prioritized, to me they were so complicated that I had to ask how they functioned before I was able to draw a path. When this sort of thing happens it is often a good indication that the code does not make sense and should be reworked!


In this case, after some discussion we decided to merge the Path blocks with the Shape blocks. The Path and Shape blocks were already quite similar, both are used to draw something to the canvas, but the Shape blocks were much easier to use. We altered the Path blocks so that they could each be drawn as a standalone object, rather than a group of paths, just like the Shapes. In the background there were many changes that needed to occur to change the functionality of the Paths, but from the user’s perspective, the result was just a more concise set of blocks that all had the same functionality and were simple to use!


Refactoring code makes it easier to add new features to a program, and reworking code makes for a more user friendly program! Therefore it is good practice to do these things frequently during the development process. And in the case of an open source project, where the original writer of the code may no longer be around, it is especially important to keep an eye out for code that needs refactoring and to try out all parts of the program, not just what you are working on, to make sure everything is working well, and makes sense! Doing these things will help ensure your program is at it’s best!


Written on November 16, 2015