31 lines
1.1 KiB
Markdown
31 lines
1.1 KiB
Markdown
|
---
|
||
|
img: /img/settings.png
|
||
|
title: "Boolean Variable Names"
|
||
|
author: Jeff Russo
|
||
|
pdate: FILL_IN_DATE
|
||
|
desc: Choosing a good boolean variable name
|
||
|
---
|
||
|
|
||
|
Choosing good names for variable is important. They are a form of documentation and can remove [complexity](http://localhost:1313/blog/complexity/) from code. Using a bad name for a variable leads to confusion, bugs, and wasted engineer time. In this blog post I will discuss what makes a variable name good or bad, for [booleans](https://en.wikipedia.org/wiki/Boolean_data_type) in particular.
|
||
|
|
||
|
## Purpose
|
||
|
A boolean's purpose is to toggle between true and false. Therefore, the name should represent something that is true or false.
|
||
|
|
||
|
## Good Boolean Names
|
||
|
|
||
|
|
||
|
## Bad Boolean Names
|
||
|
|
||
|
Variable names for booleans: avoid names that are already a negation (notReady, headless).
|
||
|
|
||
|
find examples in OSS (Gitea notify)
|
||
|
|
||
|
|
||
|
Read PoP and PoSD for bool blog post
|
||
|
Use an unambiguously negatable name. No context should be needed for understanding. Ex: “FlexibleName”
|
||
|
Going between configs is problematic. Ex: confA.UseProd = !confB.NoProd
|
||
|
Should be in the affirmative (useProd, not noProd)
|
||
|
|
||
|
|
||
|
answerable with yes or no (true or false)
|