Negative Naming in Forms

Question

The Main Question

Is it ever acceptable to use a negative name for a boolean variable? For example, I have a few user forms that have a checkbox for "N/A" or "Not Assessed". These aren't going to be used as a part of any query, nor are they going to be used in any complex application logic. These checkboxes exist solely so clinicians can acknowledge that they know they didn't fill something out.

Additional Background

I normally wouldn't drag a work disagreement onto the web, but I feel like I unfortunately need backup on this one. I work with a contractor that often gets deferential treatment because of how much more his time costs. He has decided to go through and mark all of my instances of "isNotApplicable" and "isNotAssessed" as "bad code needing revision". I explained the scenario to him only to be informed that negative variable names are always bad, and that if he sees it, he will change it. It doesn't sound like the biggest deal now, but there are a few forms coming up where changing a single word could cost people things like Medicare funding, and forcing the form to use the opposite of the stored value seems like a much bigger recipe for problems.

Research

There are countless blogs and guides talking about how bad negative boolean naming is, but many of them acknowledge that there are exceptions. Unfortunately there isn't much out there to help argue that maintaining clarity between the UI and the model is more important than preventing the possibility of double negatives appearing in your code, maybe because it seems too obvious, or maybe because I am just wrong. The strongest example I could find was a line from the Dart docs. Dart: Prefer Positive Names

Answer 1

"Not applicable" and "not assessed" are the positives here. The word "not" does not change that.

Only changing isNotApplicable into isApplicable would be just wrong because the value being true would no longer align with the checkbox being checked. This would be a head splitting brain teaser to any developer. To fix this you would also have to change the UI by renaming the checkbox to "applicable" and checking it by default, requiring the user to uncheck it if he were to deem something not applicable. This would be a head splitting brain teaser to your user.

So yes, negative logic is bad but yours is not negative logic. Your co-worker is making it (partly) negative which is even worse than fully negative logic.

Answer 2

I read N/A as "Enn Aye", and all the negativity is gone. Sometimes you might have to check "if (not N/A)" and that turns into "Not Enn Aye", easy to understand. Ask your boss to reduce the man's daily rate.

Answer 3

The goal is to make it easy to reason about

The point of avoiding negative naming is to reduce the number of mental operations an engineer has to perform in their head to understand code. When things are negative (or worse, double-negative), it it more complicated to understand when compared to positive logic.

In the UI layer, the point of the code is to support the user interface. Where practical, there should be a clean mapping between UI controls, UX concepts, and internal variables. So if there is a negative control, it makes sense for there to be a negative variable associated with it. To do otherwise would require the developer to flip the logic of the UI control in order to understand the variable, i.e. add a mental operation, defeating the whole purpose.

Other layers (such as the business layer) should not have any knowledge of the UI or how data entry controls are surfaced to the end user. Thus there is not as much of a rationale to maintain the negative naming, unless that negative concept maps directly onto a business concept. In which case it is, arguably, positive.

Answer 4

I'd look at it like this:

Design the UI to client expectations. If the client wants a negative there, fine.

Design the backing viewModel of the UI to match the UI. So if it's negative, so be it.

Design everything underneath that to "normal" (non-negatives). This keeps the core system clean.

UIs are quirky for all sorts of reasons, including naming. Thus, UI code is expected to be quirky. Just draw a hard line between your presentation layer and the layers under it, and don't let the quirkiness of UI stuff leak into your core stuff.