Skip to content

camel_case_types should cover enums #58583

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

Closed
pq opened this issue Dec 6, 2021 · 6 comments · Fixed by dart-archive/linter#3125
Closed

camel_case_types should cover enums #58583

pq opened this issue Dec 6, 2021 · 6 comments · Fixed by dart-archive/linter#3125
Labels
devexp-linter Issues with the analyzer's support for the linter package legacy-area-analyzer Use area-devexp instead. linter-false-negative

Comments

@pq
Copy link
Member

pq commented Dec 6, 2021

As per the style guide:

Classes, enum types, typedefs, and type parameters should capitalize the first letter of each word (including the first word), and use no separators.

https://dart.dev/guides/language/effective-dart/style#do-name-types-using-uppercamelcase

Would be nice to have this in place in time for enhanced enums (#3090).


Alternatively, we could consider a discrete lint camel_case_enums (in keeping with camel_case_extensions).

@pq
Copy link
Member Author

pq commented Dec 6, 2021

@bwilkerson @munificent @jakemac53 @natebosch @lrhn @eernstg: any gut reactions on extending camel_case_types vs. adding camel_case_enums?

@natebosch
Copy link
Member

I would extend camel_case_types

@lrhn
Copy link
Member

lrhn commented Dec 7, 2021

Agree. Enums are classes. They are special classes with a lot of restrictions (some of which we plan to remove) and an extra syntax for creating named instances, but they are fundamentally classes and should be named the same way.

@pq pq changed the title camel_case_types should cover enums (or we should add camel_case_enums) camel_case_types should cover enums Dec 7, 2021
@bwilkerson
Copy link
Member

Agreed. Unless we have evidence that changing the rule would break too many users it would be better for users if er extended the existing lint rather than adding a new one.

@HelioStrike
Copy link
Contributor

Created a PR for this as it seemed like a good first issue... Will revert PR incase I did something wrong and there's some process to be followed for contributing. Thanks! :)

@pq
Copy link
Member Author

pq commented Jan 3, 2022

Awesome. Since this could potentially block an internal Dart SDK roll (if there are violations to address), we'll have to do some testing before landing. I'l look into that.

Thanks!

@devoncarew devoncarew added devexp-linter Issues with the analyzer's support for the linter package legacy-area-analyzer Use area-devexp instead. labels Nov 19, 2024
@devoncarew devoncarew transferred this issue from dart-archive/linter Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
devexp-linter Issues with the analyzer's support for the linter package legacy-area-analyzer Use area-devexp instead. linter-false-negative
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants