Timeline for Is there terminology for "true"ing, "false"ing, and toggling a boolean?
Current License: CC BY-SA 4.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 5, 2018 at 17:09 | vote | accept | Anon | ||
| May 5, 2018 at 17:10 | |||||
| May 5, 2018 at 15:30 | comment | added | user1118321 | 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. | |
| May 4, 2018 at 16:53 | comment | added | Morgen | @Flater interesting conversation aside, I think we're moving into "extended chat" territory | |
| May 4, 2018 at 16:50 | comment | added | Morgen | @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. | |
| May 4, 2018 at 16:39 | comment | added | Flater | @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. | |
| May 4, 2018 at 16:33 | comment | added | Morgen | @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". | |
| May 4, 2018 at 16:24 | comment | added | Flater | @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) | |
| May 4, 2018 at 16:17 | comment | added | Morgen | @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. | |
| May 4, 2018 at 12:51 | comment | added | Flater | @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) | |
| May 4, 2018 at 12:48 | comment | added | Cubic | @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. | |
| May 4, 2018 at 12:42 | comment | added | Flater | @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. | |
| May 4, 2018 at 12:39 | comment | added | Flater | 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. | |
| May 4, 2018 at 9:58 | comment | added | Cubic | 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. | |
| May 4, 2018 at 7:02 | comment | added | Pieter B | 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. | |
| May 4, 2018 at 6:00 | comment | added | Maybe_Factor | Have to agree... boolean is the implementation which models what you are REALLY talking about... so talk about that instead! | |
| May 4, 2018 at 4:35 | history | answered | user44761 | CC BY-SA 4.0 |