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.
Throughout Silverlight and WPF, properties that are boolean values are prefixed with Is (almost all), for example:
IsEnabledIsTabStopIsHitTestVisibleIn all other Microsoft frameworks (winforms, BCL, ASP.NET) Is is not used. What prompted their team to move away from the original naming convention – is it an evolution or a miss-naming that had to stick?
Personally, I always try to prefix boolean values with something that adds a little more meaning (is, has, can, etc.). My usage comes from the following Microsoft guidelines:
MSDN – Names of Type Members
I don’t believe this was always the caseThis wasn’t always the case. Those practices date back to .NET 2.0. Before that, things were fair game. Cleaning up those names in newer versions of the Framework, however, would cause all kinds of headaches (hence some of the Framework code uses the convention and some doesn’t).It definitely makes things more readable though. Even using an example from your question. Which would you rather have?
or