We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does it make sense to always favor *_enabled option names for boolean variables? Having both _enabled and _disabled is a bit confusing IMO.
*_enabled
_enabled
_disabled
Was the original purpose to set the values correctly without having to specify the options in the config file?
The text was updated successfully, but these errors were encountered:
That is exactly right LOL. I have a config overhaul planned for this sprint, so hopefully will become much easier!
The other thing to note is that there is no way to set a 0 value for some options because 0 is interpreted as desiring default. 🤦
0
default
Sorry, something went wrong.
Successfully merging a pull request may close this issue.
Does it make sense to always favor
*_enabled
option names for boolean variables?Having both
_enabled
and_disabled
is a bit confusing IMO.Was the original purpose to set the values correctly without having to specify the options in the config file?
The text was updated successfully, but these errors were encountered: