Styling for code blocks. (#23)
Revert back to a code block. Style for code blocks.
This commit is contained in:
parent
46816ac651
commit
58008d1e2a
@ -340,3 +340,11 @@ button.round, .btn.round {
|
||||
}
|
||||
|
||||
.blue { --clr: #42A5F5 }
|
||||
|
||||
pre {
|
||||
background: #eee;
|
||||
border-radius: 5px;
|
||||
padding-left: 1rem;
|
||||
color: black;
|
||||
font-size: 0.95rem;
|
||||
}
|
||||
|
@ -20,7 +20,11 @@ A boolean name should give the reader more clarity as its scope expands. A bool
|
||||
## 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. '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.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user