diff --git a/content/blog/boolean_names.md b/content/blog/boolean_names.md index 7de76e7..2005f58 100644 --- a/content/blog/boolean_names.md +++ b/content/blog/boolean_names.md @@ -1,34 +1,33 @@ --- -img: /img/settings.png +img: /img/yinyang-simplesystems.png title: "Boolean Variable Names" author: Jeff Russo -pdate: FILL_IN_DATE +pdate: June 50, 2020 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 can be true or false. +Choosing good names for variables 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 [boolean](https://en.wikipedia.org/wiki/Boolean_data_type) variable name good or bad. ## Good Boolean Names +Boolean names should be negatable, and in the positive form. These names should be clear and concise just as all variable names should be. As the scope of the variable increases, it's level of description should increase as well. +The book, _The Elements of Style_ 1, is a concise guide to writing English. Some rules can be used as a guide for writing code as well. For example, rule 11, "Put statements in positive form," can be applied to naming boolean variables. In code, there is one additional requirement: the statement must be positive as well. 'enabled' is in the positive form and a positive statement. 'disabled' is in the positive form, but is a negative statement. 'notEnabled' is both in the negative form and a negative statement. + +In English, it is best to use enabled or disabled, and to avoid "not enabled"; they are more concise and stay in the positive form. The extra requirement of using a positive statement for boolean names is because boolean variables' negations have meaning as well; in writing "not disabled" is a double negative and is discouraged. In code, '!disabled', is also a double negative, and should be avoided. + +A boolean name should give the reader more clarity as it's scope expands. In [Go](https://play.golang.org/p/i1W05p5EpAN), a boolean variable that exists for the scope of an if statement may have a short name ('ok'). If this variable was in scope throughout the function, it would become meaningless. ## Bad Boolean Names +As with many things in software engineering, it is easier to find mistakes than to do something correctly the first time. Here are some naming conventions to avoid: +1. Names that are already a negation. 'notReady' and 'notProd' may make sense in one use case, but becomes confusing in a larger context. This can lead to code such as, `confA.useUAT = !confB.notProd`. This is both hard to read and ambiguous (what if there is a third environment). -Variable names for booleans: avoid names that are already a negation (notReady, headless). +2. Names that are not negatable. A name such as, 'sheets', has ambiguous meaning. It probably has something to do with a spreadsheet, but it is the writer's responsibility to prevent the reader from needing to do an investigation. -find examples in OSS (Gitea notify) +3. Names that are in negative form. These usually appear when the typical behavior is the negative form. For example, 'disabled'. Keep all the names in positive form to avoid a future headache explaining what the billing system does when it's "not disabled". Is it enabled, or is it just not disabled? -The book, _The Elements of Style_1, is a concise guide to writing. Some rules can be used as a guide for writing code as well. For example, rule 11, "Put statements in positive form," can be applied to naming boolean variables. Keep boolean names in the positive as well, with one additional requirement: do not use the positive form of a negative statement. `enabled` is in the positive form and a positive statement. `disabled` is in the positive form, but is a negative statement. `notEnabled` is both in the negative form and a negative statement. In writing, it is best to use enabled or disabled, and to avoid "not enabled"; they are more concise and stay in the positive form. The extra requirement of using a positive statement for names is because boolean variables' negations have meaning as well; in writing "not disabled" is a double negative and is discouraged. In code, `!disabled`, is also a double negative, and should be avoided. +4. Overly general names. As discussed earlier, this depends on the scope of the name. Avoid using a name such as, 'on'. It leaves questions in the reader's mind such as, "What is on?". The exception to this is typical boolean names used across code bases; Go's 'ok' is an example of this. - -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) +## Conclusion +This blog post discussed a goal to aim at (good names), and several things to avoid (bad names). Combined, these will hopefully increase the readability of your software! 1 https://tinyurl.com/y3uxhzxc diff --git a/static/img/yinyang-simplesystems.png b/static/img/yinyang-simplesystems.png new file mode 100644 index 0000000..7bba262 Binary files /dev/null and b/static/img/yinyang-simplesystems.png differ