Phil Karlton famously said, “There are only two hard things in Computer Science: cache invalidation and naming things”. If your code will ever be read by anybody (including yourself) anytime after it’s first written, naming is important. A variable named “x” has no meaning in most contexts, and neither does “thingWhichDoesSomething”. Chapter 2 lays down a lot of rules (of thumb) for naming variables, classes, methods, interfaces, etc.
One of the rules states that interfaces/implementations should not be named “ISomething” and “Something”, but rather “Something” and “SomethingImpl”. This rule stood out from the other rules because it’s one that I disagree with. I think this is mainly due to me being a .NET developer, where “ISomething” interfaces are common in the framework itself (IEnumerable, IList, etc). Clean Code uses mainly Java examples, so this might be a convention that’s widely accepted outside of the Microsoft world. Of course, in Ruby, Python, etc, this isn’t even an issue. I totally understand Uncle Bob’s reasoning, and I’ve even seen the “Impl” naming used in .NET apps before, but I think I still prefer the “ISomething” naming.
A book that I read some time ago, Framework Design Guidelines, details many of the naming conventions and styles that the .NET framework developers used. I found this a very entertaining read, and I think it provides a great baseline for .NET developers to work from, even if they aren’t writing frameworks/APIs all the time. I think Chapter 2 is also a good baseline, but in the end, naming is about communication with other developers, and following a particular language/platform idioms is important to reducing confusion.
Write a response