What is it about?
Article treats about naming convention for boolean variables and functions (selectors) in context of React+Redux stack because I found people are confused about it.
TL;DR
You should use verbs like is
or should
in selectors. Consider selectors as questions and variables/constants as the place where you keep the answers to them. Nouns like car
, admin
or more complex sentences like affirmative statement eg. displayAdsSection
holds answers to questions. Below example:
// define question
const shouldDisplayAdsSection = (state: State): boolean => {
return state.permissions.displayAdsSection &&
state.user.plan === 'free';
};
// ask question, receive answer then save it
const displayAdsSection = useSelector(shouldDisplayAdsSection);
// do whatever you want with answer
if (displayAdsSection) {
return <AdsSection />;
}
Explanation
Let's do a little experiment on the beginning to better understand the problem. Assume that you found in project code something like this:
...
const isItBoolean = ...;
...
What is your guess? What do you think hides under const isItBoolean
? Is it actual boolean or is it a method that performs the check? I can't hear you now (but be my guest and leave your answer in comments!). I can tell my guess - selector. It is a selector. Why?
Text were inspired by argument which I had with colleagues from work. One of them wrote comment on my pull request like:
Instead of
displaySection
it should beshouldDisplaySection
. This is a boolean
And that obvious last part "This is a boolean" was a trigger. Why on earth should I add a verb to variable name to indicate boolean type? I didn't get straight answer why but I had some guess'.
We think variable named like shouldDisplayAdsSection
holds answer to the question should I display ads section?
.
And concept is good, but the execution is bad. Indeed variable holds answer, but unfortunately it has a question in the name. So, when you look at it, it produces more questions - should I display section? Should I? Maybe not. Are you asking me? Why you making me decide?
Reading the code should remove questions, not creating them. We spend a lot of time on reading code not writing it, this is the reason why we should care about proper and easy to read names.
Solution to above is very simple if we adopt the principle of naming variables with affirmative statements. According to principle, variable which holds the answer may look like displayAdsSection
.
Better? IMO yes. We eliminate the question. We have a valid affirmative statement. But... if we have the answer where is the question now?
Selector is our question. In general methods and functions are our questions. They contain some instructions that define questions. For selector we can recycle eliminated earlier name: shouldDisplayAdsSection
.
And here is the code with applied above rules:
// define question
const shouldDisplayAdsSection = (state: State): boolean => {
return state.permissions.displayAdsSection &&
state.user.plan === 'free';
};
// ask question, receive answer then save it
const displayAdsSection = useSelector(shouldDisplayAdsSection);
// do whatever you want with answer
if (displayAdsSection) {
return <AdsSection />;
}
Problems
In real life of course you will face some more sophisticated problems, for example like this
class Car {
//...
}
interface State {
car: Car
}
const isCar = (car: any):car is Car => car typeof Car;
const selectCar (state: State): Car => state.car;
// here we have some problems...
const car = selectCar(state);
const car = isCar(car);
which one should be named car
? Remember, this is a naming problem, try to play with more specific names for selectors or think about synonyms, maybe something fits better. I see it like this:
const isTypeofCar = (car: any):car is Car => car typeof Car;
const selectCar (state: State): Car => state.car;
const car = selectCar(state);
const typeofCar = isCar(car);
if (typeofCar) {
render(car);
}
Summary
The only standard you need for booleans is an affirmative statement that evaluates to either true or false, this rule works across languages and frameworks. Thanks to above rules your code will look more like sentences written in natural language, which will translate into better readability for your colleagues and future you.
Top comments (0)