-
-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: