Name with intention not implementation

If you’ve been programming for a few years now, you’ve likely come across this quote:

There are only two hard things in Computer Science: cache invalidation and naming things.

- Phil Karlton

Taking some time to name things right is one of the best time investment you can make early on in a project. Make sure you’re using the same language as your colleagues and customers. If you’re not, you’re probably not going to implement the right thing.

As for intention vs implementation, make sure to objects/methods/etc. after what they’re supposed to do and not how they’re supposed to do it.

Why? One is easy to read, use and tweak; the other is usually much hard to reuse and refactor.

Here are some examples (simple on purpose):

Objects

CollectionOfItems (bad) vs Invoice (good)

Methods

callAfterDelay (bad) vs debounce (good)

CSS classes

red (bad) vs text-danger or text-error (good)

At first sight, the “bad” version may seem easier to reuse, sure you can use the CollectionOfItems object to store all sorts of items, but in practice you’ll likely end up mixing the logic of invoices and other object types in that class.

There are valid use cases of the “implementation” version as utilities. If you do end up using them, resist the urge to add logic unrelated to the utility (ex: red means red, nothing else).