simplesystems/website
simplesystems/website
1
0
Fork 0
Code Issues 18 Pull Requests Actions Wiki Activity

Styling for code blocks. #23

Merged
jeff merged 2 commits from boolblogpost-changes into BlogPost_BooleanNames 2020-07-30 03:31:10 +00:00
Conversation 0 Commits 2 Files Changed 2 +5 -1
1 changed files with 5 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 0c671c9827 - Show all commits

6
content/blog/boolean_names.md
View File

@ -20,7 +20,11 @@ A boolean name should give the reader more clarity as its scope expands. A bool
## Bad Boolean Names ## 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: 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. 'featureTurnedOff' and 'notProd' may make sense in one use case, but they become confusing in a larger context. The following code is both hard to read and ambiguous (what if there is a third environment). 1. Names that are already a negation. 'featureTurnedOff' and 'notProd' may make sense in one use case, but they become confusing in a larger context. The following code is both hard to read and ambiguous (what if there is a third environment).
<p class="friendly">confA.useProd := !confB.notProd</p> ```go
confA.useProd := !confB.notProd
```
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. 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.