Skip to content
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

Incorrect prefix suggestion for enums #123

Open
clehene opened this issue Aug 20, 2022 · 5 comments
Open

Incorrect prefix suggestion for enums #123

clehene opened this issue Aug 20, 2022 · 5 comments
Labels
question Further information is requested

Comments

@clehene
Copy link

clehene commented Aug 20, 2022

"Value name of root enum should be start with enum name"

https://google.aip.dev/126

All enum values must use UPPER_SNAKE_CASE.
The first value of the enum should be the name of the enum itself followed by the suffix _UNSPECIFIED.
An exception to this rule is if there is a clearly useful zero value. In particular, if an enum needs to present an UNKNOWN, it is usually clearer and more useful for it to be a zero value rather than having both.
The other values should not be prefixed by the name of the enum itself. This generally requires users to write MyState.MYSTATE_ACTIVE in their code, which is unnecessarily verbose.

@devkanro devkanro added the question Further information is requested label Aug 21, 2022
@devkanro
Copy link
Owner

Note that some languages (including C++) hoist enum values into the parent namespace, which can result in conflicts for enums with the same values in the same proto package. To avoid this, multiple enums in the same proto package must not share any values. To avoid sharing values, APIs may prefix enum values with the name of the enum. In this case, they must do so consistently within the enum.

I make this rule by this note, maybe I need a setting page to config AIP spec.

@devkanro
Copy link
Owner

It will relate to #45

@clehene
Copy link
Author

clehene commented Aug 21, 2022

@devkanro one thought - maybe it would make sense to externalize/delegate linting to a separate tool/config

@devkanro
Copy link
Owner

Separate tool can't provide quick fix advice (fix one file/ fix one line).
I think it's worth integrating lint functionality into language plugins for smarter quick fixes.
This plugin is still lacking in custom lint rules, something like the api-lint.yml will be useful.

@charlie-amihan
Copy link

+1 this rule is annoying af.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants