27

Lets say I am trying to describe my code in a technical meeting.

First, I set the boolean foobar to true

and

Second, I set the boolean foobar to false

seems a bit wordy. If foobar was toggled, I could probably say,

Third, I toggle foobar

Through implication here, you know its a boolean. So shouldnt I be able to:

Fourth, I Truthify foobar

and

Fifth, I Falsify foobar

Which will also through implication, tell my listeners that we are dealing with a boolean variable? Is there proper terminology for this? Thanks.

Anon
  • 3,565
  • 3
  • 27
  • 45
  • 17
    "I set foobar to true/false" is not that wordy, and it's obvious that's a bool. "Toggle" is fairly clear to listeners, IMO. – Filip Milovanović May 04 '18 at 09:20
  • 8
    "First, I set the boolean foobar to true and, Second, I set the boolean foobar to false". Couldn't you have just set it false in the first place? ;) – David Arno May 04 '18 at 09:38
  • 2
    I always thought it was called flipping, but apparently [that's the term for bits](https://en.wikipedia.org/wiki/Bit_flipping), not bools – e_i_pi May 04 '18 at 09:46
  • 17
    I'd read *falsify* as equivalent to creating a forgery and not setting the value to false. – CodesInChaos May 04 '18 at 09:50
  • 6
    Are you sure you're expected to describe your code on such a low level? Surely if someone wants such a low level description, they'd just read the code. I'm not saying there's *never* a reason to use such terminology, but I would expect it to be rare. – Bernhard Barker May 04 '18 at 10:44
  • Maybe this question would attract good answers on ELU also. – Lorraine May 04 '18 at 11:38
  • 1
    "falsify" is really ambiguous. You expect it to mean "set it to false", but I read that as "intentionally set it to a wrong value". False and wrong are two very different things in a logical context. – Flater May 04 '18 at 12:33
  • @Wilson: ELU tends to not want to touch jargon with a ten foot pole. The question is likely to get closed or receive a non-programming-specific answer. – Flater May 04 '18 at 12:34
  • Are nullable boolean types out of scope here? – Freiheit May 04 '18 at 13:24
  • How does "First he falsed that boolean, but then he trued it." sound? (English isn't my mother tongue, so native english speakers would just tolerate that without correcting me.) – LukStorms May 04 '18 at 15:15
  • 1
    @LukStorms, that sounds informal to the point of being silly to a native speaker. I might use it if I'm joking around with coworkers, though. – NH. May 04 '18 at 15:38
  • @CodesInChaos If you've read Popper, *falsify* would mean "make an observation which proves the statement false", and *falsifiable* would mean "I can think of observations that would prove this statement false, if they ever actually occurred" ;) I think you're thinking of "counterfeit" or "fake". – Andres F. Mar 04 '20 at 14:50

8 Answers8

65

If at all possible, rather than focusing on the boolean value, you should try to describe what it represents. Some examples:

  • a service? start/stop instead of started=true/false
  • a special effect in a game engine? on/off
  • an electrical signal? set/reset
  • ...

This way you'd talk in more natural terms. And thus in your meeting, instead of "truthifying foobar then falsifying it" you would simply "start foobar then stop it" (if foobar is a service, indeed).

When you really need to talk about a boolean value, you can go with "set/reset", or "set to true" and "set to false". "Toggle" sounds quite nice in all contexts.

And if you work in a boolean shop (whatever that could mean) then you probably need more words than what the dictionary has to offer. In that case, truthify and falsify are simply parts of your microspeak.

  • 16
    Have to agree... boolean is the implementation which models what you are REALLY talking about... so talk about that instead! – Maybe_Factor May 04 '18 at 06:00
  • 2
    I don't like talking about setting a boolean as making it true. Because the way I work with variables they start out uninitialized, meaning basically you can't use them yet and the act of setting a variable (true or false) is the initializing. For setting to always mean true would cause confusion. – Pieter B May 04 '18 at 07:02
  • 1
    Also, this usage of terminology translates to code as well; It's often - not always of course - better to use a two value enum instead of the builtin boolean type; `signal = HighVoltage` or `signal = Active` is IMHO much clearer than `signal = true`. – Cubic May 04 '18 at 09:58
  • Note that a properly named boolean property/variable will always immediately reveal the name you should be using for the values. Think of `isStarted`, `isActive`, `isCaseSensitive`, `mockConnection`, ... @PieterB: I partially agree with you. "Set the boolean" does not inherently mean setting it to true. However, "Set the `isActive` flag" can reasonably be interpreted to mean setting it to true. – Flater May 04 '18 at 12:39
  • 2
    @Cubic: I disagree. Future expansion aside, a binary enum seems unnecessary. `signal = true` is indeed not clear, but if you're going to use `signal = Active` then you might as well use `isSignalActive = true`. Note that this applies mainly to descriptors that are clearly mutually exclusive and exact complements. Active/Inactive fits the bill. HighVoltage does not, since "not high voltage" could e.g. mean "low voltage", or it could mean "low or medium voltage". In the latter case, the boolean argument obviously does not apply. In the former, it does. – Flater May 04 '18 at 12:42
  • @Flater There are a bunch of two state things for which this applies, and not all of those are easily solved with naming functions or variables; Such as function parameters or return values. Sure, it's not "necessary" but then again, what is necessary? In any case I am currently dealing with a codebase that has booleans liberally sprinkled all over the place and it's _very_ hard to follow what a 'true' or 'false' means in context in a lot of places; And I'm very unconvinced that just declaring an enum wouldn't improve things here. – Cubic May 04 '18 at 12:48
  • 1
    @Cubic: I'm not saying the enum wouldn't clarify things. I'm saying that there are plenty of cases where the level of clarification that the enum brings is not necessary if the boolean value is properly named. As per your statement, I disagree that it is _often_ the better approach. In cases where a boolean leads to semantical ambiguity, I would agree. But those are not the majority of use cases for a boolean value (e.g. your `signal = Active` example is _not_ a case of semantical ambiguity with a properly named `isSignalActive` boolean. The issue with `signal` is its **name**, not its type) – Flater May 04 '18 at 12:51
  • 1
    @Flater - side note: the name of a boolean parameter is largely irrelevant if the language does not support naming arguments. Java has plenty of APIs which require opaque calls like `apiObj.foo(false, true, true, false)`. Binary enums would greatly help the clarity of these calls, and prevent accidental transposition of arguments. – Morgen May 04 '18 at 16:17
  • 1
    @Morgen: But then we're specifically talking about the readability of **literal values**, not variable names. Because the same Java call would be clear if variables were actually used instead of literal boolean values: `apiObj.foo(isEnabled, isDeleted, writeLogToDatabase, writeLogToFile)`. Your argument is effectively no different from saying that `12` is less readable than an aptly named constant `MONTHS_IN_YEAR` (which I do agree with, but is not really a counter to what I said in the earlier comments) – Flater May 04 '18 at 16:24
  • 1
    @Flater true, in part, though it discounts how much easier it is to give those variables meaningful names if the literal values have semantic meaning. `lastSignal=ACTIVE` is easier to work with than `isLastSignalActive=true`, and requiring callsites to declare variables simply to make the calls readable is shifting an unpleasant amount of work to the callers - it's common, but still impolite. Regardless, my point is primarily that, when chosing between exposing a boolean or binary enum, there are other considerations than "can this be assigned to a variable in a clear manner". – Morgen May 04 '18 at 16:33
  • 1
    @Morgen: I disagree. (1) `lastSignal=ACTIVE` The name of the variable makes me expect that it contains an object of type `Signal`. It does not clearly reveal that it only contains a value pertaining to the state of the signal. (2) `requiring callsites to declare variables simply to make the calls readable ` The callsites aren't making the calls readable, they're **making their own hardcoded values readable**. The values a callsite chooses to use are their own responsibility. (3) As to your last sentence, the distinction is whether there are (semantically) more than two possible states or not. – Flater May 04 '18 at 16:39
  • 1
    @Flater fair point: `lastSignalState` would have been a better name, but the rest of the point stands. For the second point: hardcoded values will have to be present somewhere, even if that's in a config parser somewhere, it's polite to make it easier to do the right thing than not. For the last point, the distinction isn't just the number of states, it's also the context in which those states are valid. Part of the reason `null` is so pernicious is that it's valid in all contexts. Boolean parameter and toggles have this same issue: the compiler can't detect use in incorrect contexts. – Morgen May 04 '18 at 16:50
  • 1
    @Flater interesting conversation aside, I think we're moving into "extended chat" territory – Morgen May 04 '18 at 16:53
  • I recommend avoiding "set/reset" as it's highly confusing terminology. To set it is to make the value true, or 1 or positive. To reset it is to... make it true again? No, that's not right. Reset it to true? No, that's the same thing. DangitI always have to stop and think about it. – user1118321 May 05 '18 at 15:30
55
  • Setting a value to true is setting it
  • Setting it to false is clearing it.
  • Changing the current value is toggling it.

You can also use "setting it to true" and "setting it to false", of course.

user253751
  • 4,864
  • 3
  • 20
  • 27
  • 12
    I don't correlate setting a value to false as clearing it. Clearing for me means: neither true or false. – Pieter B May 04 '18 at 06:57
  • 49
    @PieterB: Well, it depends on the context; if we're talking about a Boolean flag, then "setting" and "clearing" the flag is a fairly common terminology. – Filip Milovanović May 04 '18 at 09:18
  • 7
    @FilipMilovanović In the context of variables, setting a variable means assigning a value to said variable, in the context of boolean variable this value can be true or false. It would be strange to say: hey, setting a variable means assigning a value to it...except when it is a boolean variable then actually when we set it, we mean that we assign the value : "true" – Pieter B May 04 '18 at 12:21
  • 6
    @PieterB If it can be "neither true or false", then its not a binary boolean (which is what most people think about when they hear the word), but a ternary true/false/indeterminate thing. That being said, the set/clear terminology comes from flags. Not all boolean variables are flags, so the terminology is inappropriate for many use cases. – Cubic May 04 '18 at 12:53
  • 7
    @PieterB: Yeas - it would be strange to say "set the bool variable" and to expect everyone to understand it to mean "set it to true"; but if it represents a flag, then "set the flag" is something commonly used and means set the value of the bool representing the flag to true (or the bit representing the flag to 1). (P.S. But the answer by immibis doesn't take that into account.) – Filip Milovanović May 04 '18 at 12:55
  • 1
    I more often see **reset** for making a value false. (also "set" and "reset" used adjectivally, e.g. "Bit 5 should be reset on entry"). – Toby Speight May 04 '18 at 13:16
  • 1
    In Javascript and similar, **don't** call it clearing, as that sounds like it will be `undefined` (any bool can be set to undefined in Javascript). – NH. May 04 '18 at 15:33
  • 2
    @TobySpeight Reset can also mean setting to the original value. Was your bool initialised as true? Then resetting it is making the value true. (Meanwhile clearing can sound like assigning it null, in nullable languages or types.) – doppelgreener May 04 '18 at 16:40
  • The set/reset terminology is possibly a hold-over from electronics, where the SR (Set-Reset) Latch is one of the basic building blocks of digital circuits, and the set input makes the output 1 and reset makes it 0. – mbrig May 04 '18 at 17:05
  • 2
    @FilipMilovanović: The main distinction there is your use of **flag**. The same would not be true if you used "boolean" instead. Flags are semantically set/raised and cleared/lowered. They aren't really considered as a field that holds a value, but rather a present/absent inherently defined trait. Yes, they take the shape of a boolean, but _semantically_ there is a difference between "set the flag" (implies true) and "set the boolean" (does not imply a particular value). Similarly, "clearing the boolean" removes **any** value; whereas "clearing the flag" sets the boolean value to false. – Flater May 04 '18 at 18:01
  • @Flater: But I don't disagree - you just wrote (more or less) everything I wrote, only in different words. I did say that this usage makes sense in the context of flags, and that this answer doesn't account for that (doesn't account for the fact that the usage is restricted). – Filip Milovanović May 04 '18 at 20:24
  • 1
    "Set" and "clear" are common when talking about hardware flags in various processors, and I've often heard them applied to boolean software variables in close-to-the-metal languages as well. Presumably because of a cultural connection. The notion of a "boolean" having a third state is ... a bit oxymoronic on that face of it, even if it makes sense in context. – dmckee --- ex-moderator kitten May 04 '18 at 21:16
  • True | False | FileNotFound https://thedailywtf.com/articles/What_Is_Truth_0x3f_ – Tim Sparkles May 04 '18 at 21:22
  • That terminology is definitely applied to _bits_, also good for flags, but I'd personally be confused by using it for generic boolean variables. Especially _setting_ sounds ambiguous. However, that said, "flag" can by almost a synonym for boolean variable. – Frax May 04 '18 at 22:04
1

I like "set" / "clear", but be careful of ambiguity in your phrasing. As Filip points out, "set the bool variable" could be taken to mean writing some value to the variable. But "setting the flag" is more clear.

Related terminology: turning a 0 / non-zero integer into a 0 / 1 value is called "booleanizing".

If you actually use the 0 / 1 value as an integer (instead of as a true/false bool), you may want to use that word. Otherwise it will probably only come up if you're talking about the cost of the operations the compiler has to perform. (Or if you're manually vectorizing with a SIMD compare to produce all-zero / all-one bits in each vector element).

In C and C++, a bool can implicitly convert back into an integer as 0 or 1, and on normal implementations bool is stored as a one-byte value that is either 0 or 1 (not just any non-zero value). The allows efficient a && b, but in practice many C compilers have missed optimizations.

bool booleanize(int a) { return a; }   // C++

That function compiles to multiple instructions (not including the ret) on most architectures. (MIPS being an interesting exception, having compare-into-register instructions instead of a separate flag / condition-code register). on the Godbolt compiler explorer for x86-64, MIPS, and ARM thumb, we can see the x86-64 version is:

    test    edi, edi    # set flags according to   a & a
    setne   al
    ret                 # return value in AL, the low byte of RAX

Sorry this example of what booleanizing is got a little large / off-topic!

Peter Cordes
  • 452
  • 5
  • 9
0

I think "set Foobar to true" and "set Foobar to false" are straightforward and succinct. I don't believe there are individual words for those phrases, and when you need to be both technical and precise, it's sometimes better to be willing to be a little wordy than to risk confusing your audience.

Kevin
  • 731
  • 1
  • 4
  • 15
-1

To change a boolean's value from true to false, or vice-versa is called negating.

To set a boolean's value to false is said as falsifying the boolean. I would understand you if you said "truthify", however, this doesn't sound right. I'm not sure what the verb is for making something true, so it could be right.

I would wait for someone with a better answer to come by before you start using "truthify" willy-nilly.

Anders
  • 1,321
  • 1
  • 10
  • 17
Sir Wumpus IV
  • 15
  • 1
  • 1
    The problem here is that you may use the terms *negating*, *falsifying*, but I'd use *toggle* and *reset* / *clear* respectively. In fact until reading this question, I'd never come across *falsify*. Maybe I'm just getting old though and I'm not up to date with this year's trendy terms :) – David Arno May 04 '18 at 09:35
  • 8
    'falsify' has a meaning in the english language that doesn't really align with your usage for boolean variables; If you told me you're "falsifying" your variables I _might_ understand what you're trying to say, but I'd first parse that as you trying to tell me that you're lying about the values they have. – Cubic May 04 '18 at 12:50
  • 2
    IMO the opposite of "falsifying" would be "asserting", in English, but that ("assert") gives the wrong impression to a programmer. – ChrisW May 04 '18 at 13:48
-1

"Setting" is the correct way to describe the act of assigning a value to a variable. If you wanted to get pedantic about it, you could call it "assignment", but "set" is very prevalent. In fact, it's idiomatic Java to write setFoobar() (and getFoobar()) methods to perform assignment. C# takes it a step farther with get and set property definitions.

With regards to your second point about using "truthify" and "falsify" to "through implication, tell my listeners that we are dealing with a boolean variable", you are already telling your listeners the variable is Boolean when you say:

I set Foobar to true

Harrison Paine
  • 215
  • 1
  • 4
-1

Assert or Retract can also be used, most often when talking about propositions rather than simple variables, for example in Prolog.

Assert is also fairly common in hardware, meaning to make the signal equivalent to logical true, which is usually a non-zero voltage. See the question on the electronics sister site What does it mean to "assert" a pin?.

Usually there are different terms depending what the boolean represents, rather than one general term for all languages having boolean values (set/clear flag or bit, enable/disable device or mode, assert/retract proposition, probably more).

Pete Kirkham
  • 1,798
  • 14
  • 15
  • I'd agree with *assert*, except that to a programmer that already means something else different (e.g. throwing an exception if the expression is not already true). – ChrisW May 05 '18 at 13:33
  • @ChrisW I don't know what you think people who program Prolog are if not programmers, but it was used in Prolog in 1972, so it's the C macro that changed the existing meaning. – Pete Kirkham May 08 '18 at 08:43
-3

A boolean is a the equivalent of an SPST (single pole, single throw) electrical switch: one turns it on or off.

Nicholas Carey
  • 165
  • 3
  • 2
    "Turn on the `done` variable" or "The `error` variable is turned off" both sound a bit off, at least to me. Alternatives suggested by other answers seem more prevalent - "Set the `done` variable/bool/flag [to true]", or "The `error` flag is cleared." – Sebi May 05 '18 at 00:16