Words are Easy

28 May

There are 2 kinds of words that, when combined, produce clear code:

1. Domain Words: Words users use to talk about things in the domain of value. E.g. in aerospace engineering, domain words would include “decalage”, “flap”, “camber”, “booster”, “fuel”, etc.

2. Computer Words: Words that represent computer things, like “button”, “icon”, “app”, etc. These are usually words that users would use to talk about their understanding of the application in a support call.

Other words slow us down.

Good names:

• hideDecalage
• rotate_flap
• SaveDesign
• undo
• sign_in
• boosterClicked

Bad names:

• tap
• publishReplay
• Zip
• search_utilities_service
• changeDetectorRef
• triggerEventListener

(Okay, maybe not always “bad” but they would need to be used in lower levels of abstractions and rarely in the business logic. If the code is over 20% “bad” names, the code is bad.)

It’s about time and value

Our time is best spent writing code that directly creates value. That means writing code that directly relates to the domain of value. And that means your code should read like the requirements. If there’s a mismatch it will readily stand out when using good names. A new requirement will fits right in.

On the other hand, when your code is using a lot of words not from the domain of value, you’re inefficient. You’re wasting time writing superfluous incantations which will waste even more time deciphering later.