Uncle Bob's chapter about names is one of my favorite parts of this book. I firmly believe that code should approach a level of readability where it's almost like prose. The closer your code gets to being a story of what's happening, the easier it is to understand. I find that many programmers don't spend enough time reading their code after they write it, like reading it out loud, so that they can see if the code is *saying* it does what they think it does. In our TDD sessions, my teammates and I can spend a few minutes trying to come up with just one good name for something. I've noticed that most of the time, they'll just sit there and bounce ideas around in their heads and I eventually ask them to just do the refactoring and TRY it to see if it works. We'll read the code again with the new name and keep going if it still doesn't fit. Sometimes we'll really struggle so we just settle on a "good enough for now" name and add a task to come back to this name later to see if we can come up with a better name. Sometimes it takes a bit more coding in some related area to figure out what a better one would be.
Take for example the names in this
thread:
https://coderanch.com/t/639825/java/java/java-beginner-code
I suggested method names like hit, take, effectsOf, inProgress. Campbell suggested sufferAttack(), similar in purpose to take(). This got me thinking about the thought process that goes into picking names and here are a few of the guidelines that I use:
1. Names should be short, simple, and to the point.
2. Method and parameter names should help tell a coherent and cohesive thought. I would prefer
take(Blow) to
sufferAttack() or
sufferAttack(Severity)
3. Avoid redundancy: Prefer
effectsOf(Blow) to
effectOfBlow(Blow)
4. Strive for symmetry:
hit() is not very symmetrical with
take(). I might settle on
deliver(Blow) and
receive(Blow) instead.
What is your thought process when trying to come up with good names in your program?