-
-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
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
Class constants naming #47
Comments
#42 is probably relevant here. I tried getting it to work for my interest which didnt seem to work for me. (unclear why) |
Adding:
Seems to do the job. Again, not sure if this should be added because I am not sure if the XO guideline considers this a constant or a class property. |
I'm fine with allowing upper case static properties, but it should also camel case. |
I’m not sure why this would be an exception to the current naming rule. The same request but for top-level constants was rejected, if I remember correctly. Either both should be allowed or neither. (I’d prefer both, but…) |
Currently, the ESlint configuration will mark constant properties on classes as errors. For example:
Will be considered an error, as they are expected to follow the camel case convention used for other mutable or instance-specific values, despite being an immutable constant.
Unless this is intentional, maybe it could make sense to add a rule to force attributes tagged with
static readonly
to follow the sameUPPER_CASE
format as the rest of the constants.The text was updated successfully, but these errors were encountered: