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):
CollectionOfItems (bad) vs
callAfterDelay (bad) vs
red (bad) vs
At first sight, the “bad” version may seem easier to reuse, sure you can
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).