Naming Things: The Hardest Problem in Software Engineering

This book takes on one of the hardest challenges in writing software, naming things, and done beautifully with respective resources.

I found this book pretty useful. The rules were thorough, but easy to follow and the examples were for problems I see all the time. There were some sections outside of the principles/rules that don’t seem as useful to me right now, but I can see myself reading them again later when I want to think about different naming topics. Overall, very pragmatic!

The book is good, interesting, I think the first one that really gives the deserved attention for how important is naming in software engineering. I wish the book was longer, it’s really short, and with more real world examples. It feels like the writer was in a hurry to publish the book. Anyway nice initiative

I had high hopes that this would contain practical best practices for naming. However this "book" that is not much thicker than a pamphlet where 15 of the 97 pages are preamble has very little useful information, and almost all of it is only applicable in limited situations.

This thin book, if read by software engineers, and taken to heart, would improve code quality everywhere. Just naming things properly is an incredible way to write correct code in the first place, or improve it when you find problems. And it really is the hardest problem in software engineering - it's so hard to even name things at all that coders will do things they know are wrong to avoid it: long long methods with all code inline, class names that are just some noun with "Manager" or "Factory" or "Processor" or "Action" tacked on to the end as if that was sufficient to let you know what was going on, throwaway names that don't describe the entity named, not changing test names to reflect changes in the test (many times the test name doesn't even accurately state what the test is testing!), etc. etc. Yet I have found over and over that naming things properly - and breaking things out and giving them a name - contributes significantly to correctness. The most obvious way is that a correct name breaks the connection between one section of code and another section - especially if that other section would be embedded in the first one if you didn't break it out to give it a name. * You start with the named thing: you read the name, understand what it is supposed to do, then you read the code there, locally, and decide if it does what the name says it does. * Now you go back to where the name is used - you know the name accurately describes what's going to happen so you can consider it's use right there without referring again to the code behind it. Another way proper naming works well is if you name things in such a way that uses of the name in conditionals makes everything simpler. * This is why in code reviews I constantly point out that expressions used in conditionals should be: * Broken out into a named predicate (even if only a local Predicate - maybe especially then) * And that the predicate name should be positive * Because IMO it leads to much easier to understand boolean-valued expressions In 30 short pages this book lists the rules you need to follow to name things properly. And you've probably heard each on of rules principles before, one at a time. The value of the book is that these rules are organized into 4 principles and explained together in a way that it all hangs together, and then the principles - and many of the rules - stick in you mind, where you can have them ready when you need to name something. There's another 30 pages on how to apply the principles/rules in various settings. $10 on Kindle and well worth it. Even pay the extra $5 and get it in paperback - it's small and thin and very easy to flip through to refresh your understanding with.

I like the message and the general lessons and rules are well presented. The trouble is that they are presented over and over and over again. It's almost like this should have been a blog post rather than trying to pad it out into book length. I quit reading it about 75% of the way through, I couldn't take it anymore. I get it.

It's odd that a book on this topic hasn't been written before, and I'm glad it now has. This slim volume contains a wealth of good practical advice and wisdom gained through experience. There’s something to be gained for programmers at every level–it’s tempting to say it’s most beneficial to developers early in their career, but I’ve struggled through codebases written and maintained by experienced teams that were less readable than they should have been due to unfriendly naming choices. My personal challenge: slipping jokes or pop culture references into code. But as the book rightly points out, a clear identifier is “even more timeless” than name-dropping Metallica albums. When I first skimmed the table of contents I thought it might benefit from a chapter on cloud computing and naming in the context of Infrastructure as Code, but the concepts are sufficiently general as to cover that. It can be a little repetitive about the most important points it makes, but the specifics in each chapter are unique, and it’s a relatively light time commitment, so well worth the effort. I’ll be including a copy in our onboarding package for newly hired engineers.

There are plenty of great nuggets of wisdom in this book. While some guidance is inherent, it solidifies many ideas that should be common knowledge (but definitely aren’t). Well worth the time and money to read. I’d highly recommend this book.