What I mean is: some boolean flags are perfect for the real world phenomenon they are representing e.g. is_light_on makes you understand perfectly that when it is true the light is on and when it is false the light is off.

There are other cases in which if you didn’t write the code and you don’t read any additional documentation, everything is not clear just by looking at the variable name e.g. is_person_standing, when true it’s clear what that means but when false, is the person sitting? Lying? Kneeling?

I’m obviously not talking about cases in which there are more states, boolean would of course not be a good solution in those cases. I’m talking about programs in which there are only two states but it’s not obvious, without external knowledge, which ones they are.

  • AlternateRoute@lemmy.ca
    link
    fedilink
    English
    arrow-up
    22
    ·
    6 months ago

    Other states are irrelevant only the true condition implied matters, it is or isn’t that one state.

    is_person_standing, is_standing, bStanding all tell you if someone is standing or NOT standing. Nothing else period. It does not matter if there could be other states as the test is one specific case.

  • hostops@sh.itjust.works
    link
    fedilink
    arrow-up
    19
    arrow-down
    1
    ·
    edit-2
    6 months ago

    One should not use boolean just because variable has only two states.

    I believe when you use boolean when enum should be used is called “boolean blindness”.

    Eg: isFemale instead of enum Sex {MALE;FEMALE} It also gives you an option to simply extend code if requirements change and there are more than two options.

  • nycki@lemmy.world
    link
    fedilink
    arrow-up
    17
    ·
    6 months ago

    if the states aren’t obvious, use an enum with two values, and name them both. Thats what enums are for.

  • arthur@lemmy.zip
    link
    fedilink
    English
    arrow-up
    17
    ·
    6 months ago

    I would use an Enum if available in the language:

    • More meaningful
    • Extendable
    • Lower chance of misuse
    • No naming problem
    • jbrains@sh.itjust.works
      link
      fedilink
      arrow-up
      4
      ·
      6 months ago

      Moreover, once you’re accustomed to thinking in these terms, it becomes safer to start with a boolean, because the refactoring path is clear: replace boolean with 2-value enumeration, then expand from there.

  • SpaceNoodle@lemmy.world
    link
    fedilink
    arrow-up
    14
    ·
    6 months ago

    In your example, it’s implied that any pose other than standing is irrelevant in that context. Why do you need to care if you don’t need to care?

    • linucs@lemmy.mlOP
      link
      fedilink
      arrow-up
      1
      arrow-down
      1
      ·
      6 months ago

      Maybe I explained myself poorly, what I was asking is about cases in which there are only two states e.g. standing and sitting and they are equally important so is_person_standing would not be a good name

      • SpaceNoodle@lemmy.world
        link
        fedilink
        arrow-up
        17
        ·
        edit-2
        6 months ago

        If that sort of distinction is important, it’s best practice to eschew the boolean type and instead define an enumerated type in order to remove such ambiguity.

        • neidu2@feddit.nl
          link
          fedilink
          arrow-up
          2
          ·
          6 months ago

          Yup. If a boolean were to be used in this case, it’d be an additional variable that you need to update in addition to Enum stance.

          No need to deal with the bool, if you can instead just check if (stance == 'standing ')

      • HandwovenConsensus@lemm.ee
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        edit-2
        6 months ago

        Couldn’t you just add a comment that says that if the variable is false, then the person is sitting?

        Or if the programming language supports it, you could add a getter called is_person_sitting that returns !is_person_standing.

  • thepiguy@lemmy.ml
    link
    fedilink
    arrow-up
    13
    ·
    6 months ago

    It shouldn’t matter if the user is leaning or jumping or whatever. If the variable says “is_person_standing” then the only information I get out of it is whether the person is standing or not. It would be much simpler to use enums to represent the state if there are such other options. If you don’t have enums in your language, then use constants.

  • otp@sh.itjust.works
    link
    fedilink
    arrow-up
    7
    ·
    6 months ago

    isOccupied is a good enough boolean for the state of the washroom stall. If you need more information, maybe another data type would be better (such as an Enumerated type).

  • ℕ𝕖𝕞𝕠@midwest.social
    link
    fedilink
    arrow-up
    7
    ·
    6 months ago

    is_person_standing is a good use case for enumeration, not a bool, if you care about whether they’re sitting or lying prone or hovering &c.

  • lapis [fae/faer, comrade/them]@hexbear.net
    link
    fedilink
    English
    arrow-up
    5
    ·
    6 months ago

    a boolean named is_person_standing seems fine when person states other than standing don’t matter to the program, except for the fact they are not standing.

    which leads to: name the boolean based on the thing relevant to what you’re building (this applies to other variable types, as well).

  • IphtashuFitz@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    6 months ago

    My favorite when debugging some code for a memory manager, written in the days of DOS extended memory, was shit_cookie_corrupt.

    The original author called blocks of memory “cookies”. If too many cookies were corrupted then eventually the function ohShitOhShitOhShit was called, which shut everything down.

  • Pappabosley@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    6 months ago

    Our IT often use a Boolean as a shortcut for figuring out things in code. For example, if there’s a charge we don’t apply to some customers, instead of setting it to zero, they’ll have a Boolean on the customer to decide whether they skip that part of the calculation. On top of this, they then name it in a way that limits how many records they have to update, this leads to many settings phrased in the negative, such as “Don’t apply extra leg charges”. As an extra layer on this, more recently they were made aware of the confusion this causes for staff and their solution was to change how end users are the question, which causes the “yes/no” in the interface to read the opposite of the “true/false” in the database

  • ____@infosec.pub
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    6 months ago

    PolicyCancelledByCarrier

    If canx notice has been received, processed, blah blah, eventually it’s set to true.

    If/when a reinstatement is received, set to false.

    Zero ambiguity, something along that line saved my tail when working with devs in different countries with different insurance customs.

    Carrier sent letter telling policy holder to get bent because “fuck you, pay me?” Field is true.

    Otherwise, or with reinstatement letter, field true.

  • RobertoOberto@sh.itjust.works
    link
    fedilink
    arrow-up
    1
    arrow-down
    2
    ·
    6 months ago

    I sometimes name booleans after the action that will be taken rather than the condition they represent For example, I might have booleans called “doQuickInit” or “invertResult”. I find this very useful when the value of a boolean is determined by a complex series of conditions that are not actually true or false.