Conclusion

• Remember that this is about enabling yourself and your teams to work more efficiently and effectively, not about following other people’s rules.
• The “best” names are the ones that either are most familiar to teammates, or which are worth learning.
• The name of a variable, function, or class isn’t just the name of that item, but the chain of names extending to the class, module, or project.
• You don’t have to have a perfect name to begin with; aim to have better names as they occur.

• If you can’t think of a good name, use a very bad one.
• Safely rename things when better names appear, though this may require changing the design to make a better name obvious.

Improving your naming skills is an ongoing journey. Start small:

1. Be conscious of the names you choose
2. Refactor ruthlessly when you find better names
3. Get feedback from your teammates
4. Practice these principles daily

Remember: code is read far more often than it’s written, especially in the age of agentic code generation. Invest the time to make the names work for your team.

• “Naming” by Tom Benner
• “Clean Code” by Robert C. Martin et al (I wrote the naming chapter).
• “Code Complete” by Steve McConnell
• Your team’s style guide and conventions

Thank you for reading the Naming Short Guide. Better naming leads to better code, and better code leads to better software.