2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns – Half-Day Sessions
2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- June 18, 2015
- Bits and Pieces
Naming is a central part of programming and vitally important. Everything has a name and the name we give something should reveal something about what it does. The difference between good names and bad ones is a key factor in the maintainability of the software we write. Here are seven strategies for creating better names.
* Use metaphors
We understand similarities of dissimilar things through metaphor. Using certain metaphors creates expectations that, as long as they are upheld, can define how to interact with a system. Metaphors are a central part of good designs and the names we use should reflect the metaphors we’re following.
* Use the active voice
Create names using the active voice. Methods are verbs, classes are nouns. Let them say what they do. Adopt conventions, like if a method returns boolean start the name with “is” but don’t overdo it, opt for clarity over convention.
* Say things plainly
SpellThingsOutInCamelCase so they’re easy to read. Don’t be afraid to create long names or even long sentences for names. In most IDEs, you’ll only have to type it once the first time and then subsequently you can type the first few letters and pick it from a popup list. Also, name things for what they do so they’re easy to understand.
* Pluralize names for their manager
Establish conventions that make sense and stick with them. For example, I like to name leaf objects that map to database records for what they represent (e.g. user, auction, etc.) If a manager is needed to aggregate these objects, I’ll simply pluralize the name (e.g. users, auctions, etc.) but if more sophisticated processing is required, for example caching or workload distribution, I’ll call out manager in the name (e.g. userManager, auctionManager, etc.)
* Spell things out
Avoid using acronyms, abbreviations, and lingo. Say what a method does in it’s name but don’t reveal how it does it. Don’t describe implementation details. Try to say what the method does from the caller’s perspective. Generally, name things generically for what they do and the names will have more longevity.
* Make names pronounceable
Naming is a primary means of communication that we are constantly referring to in our heads and among each other. It’s easier to communication and understand names that can easily be pronounced. Unpronounceable names can be confusing to work with and difficult to talk about.
* Use generic or specific names based on scope
Use short generic names for public symbols. For example, even if I’m only using one zipCompress128 object, I’ll call it compress so if I ever need to refactor to a Strategy Pattern, I don’t have to change the name. Conversely, use long specific names for privately scoped symbols so they clearly express what they do.
Naming is a critical skill that makes the software we write understandable and easier to work with. Depend on names over comments to express what code does. This helps embed knowledge in the system and makes code self-expressive instead of having to use comments. It will make all the difference when people go back into the code to work with it.
Previous Post: « Seven Strategies for Solving Problems Test-First
Next Post: Seven Strategies for Continuous Delivery »