I mean, this is overdoing it a bit and the “thisVarMakesItSoThat” part is redundant, but other than that those are very descriptive property- and method names, which is not a bad thing.
It wouldn’t need to say HighContrastForAccessibilityPurposes though, it would ideally just be HighContrast, and the “for accessibility purposes” would be a comment, right?
Variable names shouldn’t need comments, period. You don’t want to look it up every time this variable is used in code, just to understand what it holds. Of course there are always exceptions, but generally names should be descriptive enough to not need additional explanation.
And context can also come from names of other things, e.g. name of a class / namespace that holds this variable. For example AccessibilitySettings.HighContrast, where AccessibilitySettings holds all options related to accessibility.
Yeah but “HighContrast” is enough; if you need to know the Why and not the What you can find a comment at the definition. There’s not need to carry the whole Wiki article everytime you need to use the variable.
I think the argument about “for accessibility” is missing the point a little bit and a common mistake most developers make.
You should endeavour to make your interface accessible by default. You shouldn’t be thinking in terms of “okay here’s the design and here’s the design that’s accessible”, you should be considering accessibility in all of your designs.
Now that’s usually a bit harder with games because you have styles and themes that you don’t want to detract from, but if your interface causes accessibility issues, it’s generally going to be bad for people that don’t have accessibility needs as well.
Well the “Purposes” can definitly be dropped. I guess “HighContrast” would be enough if there is only a single high contrast setting, but if there are multiple then I think “HighContrastForAccessibility” would be totally fine.
I mean, this is overdoing it a bit and the “thisVarMakesItSoThat” part is redundant, but other than that those are very descriptive property- and method names, which is not a bad thing.
It wouldn’t need to say HighContrastForAccessibilityPurposes though, it would ideally just be HighContrast, and the “for accessibility purposes” would be a comment, right?
Variable names shouldn’t need comments, period. You don’t want to look it up every time this variable is used in code, just to understand what it holds. Of course there are always exceptions, but generally names should be descriptive enough to not need additional explanation.
And context can also come from names of other things, e.g. name of a class / namespace that holds this variable. For example
AccessibilitySettings.HighContrast, where AccessibilitySettings holds all options related to accessibility.Yeah but “HighContrast” is enough; if you need to know the Why and not the What you can find a comment at the definition. There’s not need to carry the whole Wiki article everytime you need to use the variable.
I think the argument about “for accessibility” is missing the point a little bit and a common mistake most developers make.
You should endeavour to make your interface accessible by default. You shouldn’t be thinking in terms of “okay here’s the design and here’s the design that’s accessible”, you should be considering accessibility in all of your designs.
Now that’s usually a bit harder with games because you have styles and themes that you don’t want to detract from, but if your interface causes accessibility issues, it’s generally going to be bad for people that don’t have accessibility needs as well.
Accessibility benefits everyone.
Well the “Purposes” can definitly be dropped. I guess “HighContrast” would be enough if there is only a single high contrast setting, but if there are multiple then I think “HighContrastForAccessibility” would be totally fine.
Exactly this, it distinguishes it from
HighContrastForNerfedPlayer