checking in
This commit is contained in:
parent
aee1b4b094
commit
5705040953
30
content/blog/boolean_names.md
Normal file
30
content/blog/boolean_names.md
Normal file
@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
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)
|
Loading…
Reference in New Issue
Block a user