What Have You Learned?

Naming is one of the hardest tasks that you face in your day-to-day developer life. Bad naming usually doesn’t stop your code from compiling (so no compiler will help you to find really bad names), but it’ll make the code much harder to read and understand. And that can turn the maintenance of your code into a nightmare.

That’s why we’ve added this chapter on naming to the book. Good naming is less clear-cut and well defined than the problems you’ve seen in some of the other comparisons here. In our experience, you’re never done with proper naming. When you look at a piece of code that you’ve written some time ago, chances are you’ll find something to improve in naming, if only because you’ve had more time to get acquainted with the terms of the domain. Our advice is to always refactor when a better name comes to your mind.

When it comes to naming, conventions are half the rent. Even if you come up with a good name, it’s going to look bad if it violates the Java conventions. Conventions are especially important for naming getters and setters, which are about the only part of Java where terrible naming can result in compile or runtime errors when you use certain frameworks. But conventions aside, good names shouldn’t be too short (be careful with single letters and abbreviations) or too long (packed with meaningless terms), and hitting the right level is really hard. Your best bet is to always align names to the domain you’re writing the code for.

In the next chapter, we’ll move back to a topic that doesn’t just influence the understandability of your code, but also its functional correctness: exception handling. No matter what type of program you write, unforeseen things can happen, and it’s your job to prepare for that. But as exception handling breaks the regular control flow, it comes with big potential for introducing subtle bugs or implementing it in a way that’s hard to understand. We’re going to show you some tips and tricks to avoid that.