BlogPost_BooleanNames #22
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