1. 18
  1.  

  2. 10

    I call this the ‘Bag o Bools’ anti-pattern. It’s particularly common (and bad) in firmware land.

    I recently saw an option struct defined with 31 booleans. With 2 billion possibilities I’m not sure how anybody could be confident about test coverage :)

    1. 4

      The article mentions that “a Robin-hood style hash table” could improve performance. That data structure is interesting, but the linked article doesn’t explain it very well. I found a better explanation here: Robin Hood Hashing – Programming.Guide

      1. 1

        put the object to a special array is just another way to set feature flag. it is just a harder to find out feature flag. Add field to a object or add field outside the object but with pointer to it.

        1. 1

          What they seem to be describing is a vague approximation of the Entity Component System pattern. The benefit is that it moves the complexity of the entire program out of the object itself and into the systems that need to know that state. Why does an entity need to know it’s visible? Shouldn’t the system handle that for all entities with that component instead? There isn’t any one answer, but this kind of pattern might simplify your program a lot.

          1. 1

            the code checking for a particular flag should put into files close to each other ( put into the same system ), that is the essence.

        2. 1

          Personally, I think this alternative is uglier and less clear than using a flag, but that’s obviously subjective. Are there objective advantages to one approach over the other? “Cache misses” seems plausible, but also seems like a very low-level detail subject to a lot of other influences - I’m skeptical without numbers backing it up.

          A third option is to use the type system. For certain attributes like dynamic vs static, this seems like the best option, IMO.