6 ms·
This is a great comment ^ whenever you use two booleans like this, you're opening yourself up to "unrepresentable state" logic errors. Finding and noticing this
by nightpool 2y ago
This is a great comment ^ whenever you use two booleans like this, you're opening yourself up to "unrepresentable state" logic errors. Finding and noticing this in code can be tricky, but it's a great example of something that should be caught during code review.
- politelemon 2y agoNot sure if exactly the same thing but reminds me of "Booleans are a trap" https://katafrakt.me/2024/11/09/booleans-are-a-trap/ https://katafrakt.me/2024/11/09/booleans-are-a-trap/
- iwontberude 2y agoYet another article prematurely optimizing. It’s like these people have nothing better to do. I’ll wait for my code to get into stupid edge cases first and then fix it. Even if you spend your time avoiding booleans you will still find yourself with some new contradictory state and have to fix it differently anyways.
- amluto 2y agoHuh? This isn’t premature optimization unless you consider trying to write correct code “optimizing”.
- lmm 2y agoComing up with proper representation for your state is almost always worth it. If anything it's the opposite of premature optimisation - normalise first, only denormalise after you've proven that it's needed.
- liontwist 2y agoThe issue isn’t booleans the issue is that the code doesn’t handle all the states described by the two booleans, when all are possible.
- cma 2y agoMake the impossible states unrepresentable using an enum of only the possible boolean combinations.
- dpig_ 2y agoIsn't that exactly what the article prescribes?
- liontwist 2y agoDid you read the context?
- cma 2y agoNo I read wrong and missed it. If all four states are actually possible an enum can still be a win if you have a compiler that can check for exhaustive switch case statements. Or especially if updating a system where it used to be only three were valid and now something changed so that all four are.
- lvturner 2y agoWait—that last state doesn't make sense. With a real door, you can technically turn the key while it's open, but does that meaningfully change its state? Yet our model allows this impossible combination. Funnily enough, I have a physical door & lock that OFTEN gets in to this state - it's exactly as irritating as it sounds, and it has very meaningful impact on it's state (it then can't be closed without first unlocking the lock!)
- pryelluw 2y agoI’ve come to the conclusion that most programming problems like this can be solved my having programmers work as building superintendents for 3 months. Practical experience will open their eyes to how the world really works.
- lvturner 2y agoThis leads to another wonderful gap, where programmers are expected to understand the world[0], but the world isn't expected to understand programming[1] [0] Business, etc [1] System design, security, database management, cost vs speed trade-offs, SCM, etc etc etc
- enugu 2y agoThis is a good account of a software modelling process. But, this is not specific to booleans. Database constraints involve the same issue. One motivation for encapsulation in software was to preserve constraints in the data (or in other words, disallow improper states). Encapsulation allows only internal functions to manipulate the data, and the developer just needs to checks that these functions are doing it correctly. Or, as pointed out in the post where multiple booleans are merged into a single enum, encode the constraints into the data itself ie. use the constraints of the host programming language. But this wont be possible in general - for instance if your language doesn't have sets/dictionaries, how would you encode uniqueness of values directly using arrays and lists? It would have to be done using interface functions.