The previous post discussed the subtle arts of naming things and not repeating yourself--and now I want to extend its observations beyond functions.
That post teased out 3 intuitions about writing lower-churn code:
-
When you re-use a function, weigh whether you're re-using it for the same reason. If the reasons differ and there isn't a strong performance argument against it, use a new name for this new reason.
-
It may be a good idea to habitually name functions with a dash of why. As the fraction of function names that encode why increases, it'll get easier (less mental work/overhead) to spot diverging purposes per #1.
-
It's probably easier to write lower-churn code in languages where you can cheaply alias multiple names to a single implementation--and you should use this mechanism to accomplish #1_.
This post will try to convince you that we can extend these intuitions to naming declarative things like CSS classes. Consider the following markup:
1<article>
2 <div class="meta">
3 Posted: <span class="date">Sunday, May 29 2022</span>
4 Updated: <span class="date">Monday, May 30 2022</span>
5 </div>
6
7 Brilliant thoughts...
8</article>
And some arbitrary CSS, like:
1span.date {
2 text-decoration: underline;
3}
Just like with the fail
function in the last post:
- the CSS class specifies some things to be done (once we declare a rule, at least)
- a single
date
class is fine as long as we don't need to discriminate between which things should be done in each instance
Once again, imagine the user report:
I really love all of the brilliant thoughts you think and I find the updates and corrections you post even more useful.
Could you make the updated dates stand out better?
Once again, we've missed an opportunity. If we had noticed that the dates had different purposes, we might've prepared by writing markup that indicated why the dates differ:
1<article>
2 <div class="meta">
3 Posted: <span class="date posted">Sunday, May 29 2022</span>
4 Updated: <span class="date updated">Monday, May 30 2022</span>
5 </div>
6
7 Brilliant thoughts...
8</article>
Note: We could use datePosted
and dateUpdated
--but HTML/CSS give us excellent affordances for efficiently aliasing complex sets of identifiers to complex sets of implementations.
I didn't find it intuitive to put imperative subroutines and declarative style rules in the same set, so I'll end this post by coining a term for this set--and then use it to restate the intuitions from the first post.
This series addresses a set of active free-form identifiers that I'll call gizmos. A gizmo is a name/label with automatic behavior attached. Gizmos include more than just subroutines like functions and methods--and more than declarative style rules like CSS classes. (I'll expand this set more as we go.)
My intuition thinks there are a few good recommendations in here for writing lower-churn code and markup:
-
When you re-use a gizmo, weigh whether you're re-using it for the same reason. If the reasons differ and there isn't a strong performance argument against it, use a new name for this new reason.
-
It may be a good idea to habitually name gizmos with a dash of why. As the fraction of gizmo names that encode why increases, it'll get easier (less mental work/overhead) to spot diverging purposes per #1.
-
It's probably easier to write lower-churn code and markup in languages where you can cheaply alias multiple names to a single implementation--and you should use this mechanism to accomplish #1.
The next post will build on the idea that CSS classes are gizmos by applying the implications to markup languages.