-3

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

Improve this question
2
  • 3
    The key word there being "prefer." I continue to be baffled by these religious arguments. Software design decisions are always tradeoffs. If you want to reverse the logic of a bound property in a MVVM scenario (say, one that enables or disables a button), do you write a Negative Boolean Value Converter class (that's going to require at least a dozen lines of code) and hook it up in your XAML (another 3 or 4 lines), or do you just provide a negative property in your View Model? The correct answer is always "it depends."
    – Robert Harvey
    Commented Aug 7, 2020 at 17:10
  • 1
    And at the end of the day, the decision is still yours to make.
    – Robert Harvey
    Commented Aug 7, 2020 at 17:16

4 Answers 4

Reset to default
3

"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.

Improve this 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.

Improve this answer
2
  • You're arguing against double-negatives, not negatives.
    – Robert Harvey
    Commented Aug 7, 2020 at 22:11
  • @gnasher729 That's how I thought of it too. "Not Applicable" is so common that you think of it without thinking "opposite of applicable". While it's linguistically negative it's kind of like saying cold vs warm, cold is the absence of heat, but you conceptualize it without thinking "not warm". I doubt they would even consider dropping his rates. We hit major issues with him not showing up to meetings or following the requirements list, and the response was "We already paid so much and he's already put in 2 months of work, we can't just find a different contractor." That was over a year ago.
    – Shaun H.
    Commented Aug 11, 2020 at 12:51
1

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.

Improve this answer
-5

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.

Improve this answer
2
  • 2
    This is too vague to be useful. You're basically saying "it doesn't matter."
    – Robert Harvey
    Commented Aug 7, 2020 at 17:11
  • 2
    What you're describing as a "ui quirk", I would call a part of the domain model. Design your app around that.
    – Avner Shahar-Kashtan
    Commented Aug 7, 2020 at 18:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.