fine, I'll use the standard spelling

This commit is contained in:
carson 2020-05-29 15:35:33 -07:00
parent 28665a8ea0
commit f501ca6f7e

View File

@ -2,19 +2,19 @@
layout: layout.njk
title: </> htmx - high power tools for html
---
## Locality of Behavior (LoB)
## Locality of Behaviour (LoB)
> "The primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a
> programmer to understand that source by looking at only a small portion of it." -- [Richard Gabriel](https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf)
### The LoB Principle:
> The behavior of a code unit should be as obvious as possible by looking only at that unit of code
> The behaviour of a code unit should be as obvious as possible by looking only at that unit of code
### Discussion
The LoB principle is a simple prescriptive formulation of the quoted statement from [Richard Gabriel](https://www.dreamsongs.com).
In as much as it is possible, and in balance with other concerns, developers should strive to make the behavior of
In as much as it is possible, and in balance with other concerns, developers should strive to make the behaviour of
a code element obvious on inspection.
Consider two different implementations of an AJAX request in HTML, the first in [htmx](https://htmx.org):
@ -37,17 +37,17 @@ and the second in [jQuery](https://jquery.com/):
<div id="d1">Click Me</div>
```
In the former, the behavior of the `div` element is obvious on inspection, satisfying the LoB principle.
In the former, the behaviour of the `div` element is obvious on inspection, satisfying the LoB principle.
In the latter, the behavior of the `div` element is spread out amongst multiple files. It is difficult to know
In the latter, the behaviour of the `div` element is spread out amongst multiple files. It is difficult to know
exactly what the div does without a total knowledge of the code base.
#### Surfacing Behavior vs. Inlining Implementation
#### Surfacing Behaviour vs. Inlining Implementation
A common conflation is surfacing behavior with inlining implementation of that behavior. These are separate concepts
and, while inlining the implementation of a behavior isn't *always* incorrect, it may *often* be incorrect.
A common conflation is surfacing behaviour with inlining implementation of that behaviour. These are separate concepts
and, while inlining the implementation of a behaviour isn't *always* incorrect, it may *often* be incorrect.
Increasing the obviousness of the behavior of an element is, ceteris paribus, a good thing, but it falls to both end-developers
Increasing the obviousness of the behaviour of an element is, ceteris paribus, a good thing, but it falls to both end-developers
and especially framework developers to make LoB as easy as possible.
#### Conflict With Other Development Principles
@ -62,7 +62,7 @@ are:
allows you to place many attributes on parent elements in a DOM and avoid repeating these attributes on children. This is a
violation of LoB, in favor of DRY, and such tradeoffs need to be made judiciously by developers.
Note that the further behavior gets from the code unit it effects, the more severe the violation of LoB. If it is
Note that the further behaviour gets from the code unit it effects, the more severe the violation of LoB. If it is
within a few lines of the code unit, this is less serious than if it is a page away, which is less serious than if
it is in a separate file entirely.
@ -75,7 +75,7 @@ are:
in isolation this may, indeed, be a good thing. Inlining styles has become more prevalent lately, but there are
still strong arguments in favor of SoC in this regard.
Note that SoC is, however, in conflict with LoB. By tweaking a CSS file the look and, to an extent, behavior of an
Note that SoC is, however, in conflict with LoB. By tweaking a CSS file the look and, to an extent, behaviour of an
element can change dramatically, and it is not obvious where this dramatic change came from. Tools help to an extent
here, but there is still "spooky action at a distance" going on.