Any fool can write code that a computer can understand. Good programmers write code that humans can understand.— Martin Fowler
Naming is one of the most frequently-used and timeless skills in software engineering, but it’s poorly understood and poorly executed. As software engineers, we generally use a great deal of structure in how we write software, but we know few best practices in software engineering’s most enduring artifacts: the names of things.
This lack of best practices leads to codebases that are difficult to understand, confusing communication, mental overhead, slow onboarding, and many other inefficiencies. How many times have you apologized for the naming of something or struggled to remember the meaning of an unclear name within a codebase? You’re not alone!
How do we fix this? As with other software engineering skills, we can develop best practices and learn how to apply them. Best practices for naming aren’t readily available. Bits and pieces have been scattered throughout blog posts and small sections in some books, but there isn’t a definitive guide on how to name things in software engineering.
Naming is important, and the best practices for it should be more accessible to more engineers, so I’ve decided to write a book about it. The working title is Naming Things: The Hardest Problem in Software Engineering. 😉
The book will describe why naming is hard but important, then describe principles for good names and how to apply them. The scope will be naming within day-to-day software engineering, focusing on the practical application of best practices for naming data models, classes, functions, and similar concepts.
This book has an audacious goal of making software engineering more efficient and enjoyable, but I’m confident that we can achieve this by applying the same practical, rigorous structure that we’ve used to improve other aspects of software engineering.
If you’d like to be notified when the book is available, click the button below:
If you’d like to know more, or would like to help with the book in any way (e.g., provide feedback on drafts), feel free to contact me!