3 ms·
This can lead to additional problems. Say Fnurbification is a setting in code wrapped in an if block. Great, on or off is easy to follow. Now say the Disable Fn
by 4RealFreedom 4y ago
This can lead to additional problems. Say Fnurbification is a setting in code wrapped in an if block. Great, on or off is easy to follow. Now say the Disable Fnurbification is what is actually in code. Now, when someone has a problem with Fnurbification, you have to map state back and see that the inverse was coded for the IU and follow that down the stack. Don't even get me started on defaults. There is no good/easy answer here.
- jefftk 4y agoThere is an easy answer: "Disable Fnurbification" is not what should be in the code. Present the right interface to the user, and fix the code when practical. Presenting something backwards to the user only makes it harder to fix later.
- 4RealFreedom 4y agoI deal with hundreds of these types of selectors from some inherited code. When a disable changes 2 lines of code to wrap functionality in an if block v adding many scattered if blocks to accommodate the enable case, I'll probably go with the low code solution. If I can easily accommodate enables then sure but it's just not always that easy.
- jefftk 4y agoThis is just about what to call the variable. Instead of: if disable_foo: ... I'm recommending: if not enable_foo: ...
- soiler 4y agothere is an easy answer if your code isn't written in a way that obfuscates its functionality to the maintainer...
- account42 4y agoThe way your code is structured should never dictate the user interface. If that is inconvenient, adjust the code not the UI.