• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Clean Code: Names

 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?


 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
On second thought, deliver() and receive() doesn't work well because of the parameters. I had:

We might have settled on hit() and take() as "good enough for now" or we might have come up with something like attack() and defend() and tried it.

That doesn't look too bad. One thing I know is that finding good names is often not as easy as you'd think it should/would be.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic