3 ms·

in the genre of naming things, some related things to explore: - avoiding naming things if you can help it - using tooling to autogenerate names - avoiding t

by swyx 5y ago

in the genre of naming things, some related things to explore: - avoiding naming things if you can help it - using tooling to autogenerate names - avoiding too short, likely overloaded names like `id`, `name`, and `url` - don't choose lazy pluralization - eg instead of `names/name`, use `nameList/nameItem` - encoding types to make Wrong Code Look Wrong, a famous Spolsky opinion (lite hungarian notation) - coming up with grammars for naming, eg React had an exercise to name its lifecycles combinations of THING-VERB-ACTION, like `componentDidMount`, before open sourcing, which helped learnability pulled from my collection of Naming Opinions here: https://www.swyx.io/how-to-name-things https://www.swyx.io/how-to-name-things

tcbasche 5y ago
>- don't choose lazy pluralization - eg instead of `names/name`, use `nameList/nameItem` Isn't this just extra noise? If the type of the variable is an Array wouldn't `nameArray` be superfluous? Worse still is if the type changes but the name stays the same. I get the advice is probably Javascript specific, but even in a Typescript world it doesn't make much sense to me to do this kind of type-in-name encoding.
- lifthrasiir 5y ago
  Even in typed languages `names` and `name` are too similar to slow code reading down.
  - berkes 5y ago
    Exactly this. In many languages the compiler will help you. But this has bitten me in Ruby, JavaScript and PHP several times. Runtime errors and downtime. Most recent: autocompled some updatedCartsItems when it had to be UpdatedCartItems. Both were used in the same class. Had they be named sensible, like CartListWithUpdatedItems and UpdatedItemList or something better, I'd have saved myself hours of WTFing through CI logs.
  - ParetoOptimal 5y ago
    Disagree, but in that case wouldn't `nameList` and `name` be best?
ParetoOptimal 5y ago
> avoiding too short, likely overloaded names like `id`, `name`, and `url` In a small enough context, no way :) > don't choose lazy pluralization - eg instead of `names/name`, use `nameList/nameItem` This just seems redundant and is a personal annoyance. Is plural meaning list or sequence not widely understood enough?

by swyx 5y ago

tcbasche 5y ago

>- don't choose lazy pluralization - eg instead of `names/name`, use `nameList/nameItem` Isn't this just extra noise? If the type of the variable is an Array wouldn't `nameArray` be superfluous? Worse still is if the type changes but the name stays the same. I get the advice is probably Javascript specific, but even in a Typescript world it doesn't make much sense to me to do this kind of type-in-name encoding.

lifthrasiir 5y ago
Even in typed languages `names` and `name` are too similar to slow code reading down.
- berkes 5y ago
  Exactly this. In many languages the compiler will help you. But this has bitten me in Ruby, JavaScript and PHP several times. Runtime errors and downtime. Most recent: autocompled some updatedCartsItems when it had to be UpdatedCartItems. Both were used in the same class. Had they be named sensible, like CartListWithUpdatedItems and UpdatedItemList or something better, I'd have saved myself hours of WTFing through CI logs.
- ParetoOptimal 5y ago
  Disagree, but in that case wouldn't `nameList` and `name` be best?

ParetoOptimal 5y ago

> avoiding too short, likely overloaded names like `id`, `name`, and `url` In a small enough context, no way :) > don't choose lazy pluralization - eg instead of `names/name`, use `nameList/nameItem` This just seems redundant and is a personal annoyance. Is plural meaning list or sequence not widely understood enough?