You just learned how to use names when investigating design issues. Most hotspots you’ll find are so complex that you need to make several passes through the code before you uncover and treat the root cause. During that time, you want to be sure the code is evolving in the right direction. Simpler and better. Here’s how.
In this chapter, we’ll use the shape of your code as a proxy for program complexity. We’ll apply indentation-based complexity measures to the hotspot’s revision history to calculate complexity trends. We’ll be able to see whether the code is deteriorating or improving over time. This is additional information we can use to prioritize the hotspots we find.
On top of that, we’ll discuss learning, encouraging design discussions, and measuring the modification effort. We’ll do this by looking at what’s not there—negative space is a new way to view your code. Let’s see it in action.