Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m trying to come up with a good naming convention for boolean variables that indicate something is “allowed”.
E.g.,
WarningAllowed or WarningEnabled (means that we have turned on the option to give a warning).
CodeComplete has some suggestion for booleans (Has<> Is<>) but those aren’t applicable.
My ideas:
I’ve seen the prefix
Canused in this context. For example:StackPanel.CanHorizontallyScrollReceiveActivity.CanCreateInstanceCanExecuteToolEventArgs.CanExecuteI like this naming convention quite a bit because it abstracts away the reason for the value, be it true or false: The user of the API usually does not have to know whether a command is not eligible because it is forbidden or because it is impossible to execute. The result is the same: a greyed-out menu item/button/whatever.
This also allows the reason to change in future versions (e.g. if a
Can*property returns false only when something is actually impossible at first, but in future versions, an access rights model is added, and from then on, the value of saidCan*property also depends on the current access rights).