Let's Refactor Some Bad Code, Part 2

One reason to spend time refactoring code is to make it livable. If you think of your code as a workshop—a place where you get work done—you want your workshop to be clean and organized so that you can spend time efficiently getting stuff done. If you have tools and materials haphazardly strewn all over your workshop, it will take longer to find the things you need, and it will be difficult to clear out the space required to do the tasks that need to get done. A messy workshop negatively affects the quality of the workmanship that's done in it. So it is with code.

Last time we did the bare minimum cleaning necessary to get a rainflow counting program in working order by giving it consistent formatting and a small set of tests. Now the goal is to target those parts of the program that make it the most annoying to work with and fix them so that the program is more well-suited for its use cases. I'll show each change to the code as a git commit, and you can follow along with the diffs in my rainflow git repository in addition to the code snippets I'll show here.

Let's Refactor Some Bad Code, Part 1

Unfortunately, we can't always be writing new code when programming. Much of being a programmer involves working with code that already exists because there is so much code out there already. There are mountains and mountains of code, and, as every programmer knows, not all of it is awesome. Sometimes this code has to be refactored to adequately maintain it, sometimes it needs to be done before new features can be shoehorned in, and sometimes it just needs to be done in order to stay sane while working with it. This is not always other people's code, either. Oftentimes it's your own code. I know I've written more than my fair share of bad code, and I may even use it as an example someday. That would be fun.