“Doesn’t That Feel Better?”

Refactoring

Probably the most crucial lesson I learned from Chris was the importance of refactoring. For the unfamiliar, refactoring is the process of editing or re-writing a piece code to improve the code quality without necessarily changing the functional behavior of the code. There are many dimensions to refactoring, and many reasons why you may want to do it. For example, renaming variables or methods in your code to be more descriptive is a common refactor that is crucial for making the code more readable. Another common refactor is to create “helper functions” that implement some shared logic which is required in multiple parts of the codebase. Helper functions can help reduce code repetition, meaning that if the shared logic needs to change in the future, the programmer only needs to make the change in one place. For more information on refactoring, I highly recommend Martin Fowler’s book of the same name.

Some IDEs will even suggest and automate refactoring for you!

“Where’s the pattern?”

Perhaps the most fun part of watching Chris code, or reviewing code that he had written was observing his ability to find and exploit patterns. I think all programmers know the feeling of writing repetitive code, and growing increasingly annoyed with it. Chris was a Jedi master of reducing previously repeated code into just a few lines of generalized code that somehow maintained the flexibility and extensibility of the original implementation, while also improving the code readability.

C++ “Lambda expressions” are a great tool for exploiting patterns.

Zero-Overhead Principle

As an audio programmer, performance is often of primary importance for much of the code that I write. With that in mind, it’s very important that finding and exploiting a pattern as in the above section does not introduce any extra performance overhead. For a long while, I believed it to be an unavoidable tradeoff: that more general code was inherently less performant, and to improve performance, it was sometimes necessary to sacrifice a little bit of code generality.

Hear Stroustrup talk about the “Zero-Overhead Principle” in C++.

Encapsulation / Modularity

No Secrets! Declare every method and variable public. After all, somebody, sometime might want to use it… This makes it very difficult to later change the way that anything works under the covers.

-Roedy Green, How To Write Unmaintainable Code

One final element of programming wisdom that I would like to share has to do with encapsulation and modularity. One of my favorite features of C++ are the public and private keywords, that are used to determine whether a member variable or function can be accessed outside of its class. While it may be tempting to make everything public (as in the tongue-in-cheek quotation above), I’ve learned that doing so can be a good way to wind up with sneaky bugs that are difficult to find the source of. For example, if I have a class with some state stored in a member variable, making the member variable private makes it easier to track where and when the state is changed, and makes it less likely that I’ll accidentally introduce a bug by doing something that I shouldn’t with the member variable.

Conclusion

Anyway, I hope this discussion has been interesting. Since meeting up with Chris, I’ve been thinking a lot about these ideas, and wanted to take a short break from writing about low-level audio DSP to share some of them. Onward!

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store