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

ENUM_FIELD_NAMES_ZERO_VALUE_END_WITH rule should not run on Enums if Go project #256

Open
Dentrax opened this issue Jul 6, 2022 · 3 comments
Labels
question Further information is requested

Comments

@Dentrax
Copy link

Dentrax commented Jul 6, 2022

By default, Go does not have enum so protoc generates an iota for enums. So we have to end the first item with zero value. This rule throws false-positive:

// protolint:disable ENUM_FIELD_NAMES_ZERO_VALUE_END_WITH
enum Result {
  FOO = 0;
  BAR = 1;
}

protolint version 0.38.2(66f8921)

What do you think?

@yoheimuta
Copy link
Owner

@Dentrax Thank you for reaching out.

ENUM_FIELD_NAMES_ZERO_VALUE_END_WITH conforms to the style guide.

  • The zero value enum should have the suffix UNSPECIFIED.

protoc generates an iota for enums

Go Reference says that protoc generates the constants without using iota.

I'm not sure what problems you have with the following code in Go project.

const (
        Result_UNSPECIFIED Result = 0
        Result_FOO Result = 1
        Result_BAR   Result = 2
)

Or

const (
        Result_RESULT_UNSPECIFIED Result = 0
        Result_RESULT_FOO Result = 1
        Result_RESULT_BAR   Result = 2
)

@yoheimuta yoheimuta added the question Further information is requested label Jul 10, 2022
@Dentrax
Copy link
Author

Dentrax commented Jul 10, 2022

Oh, thanks for clarification and references! I also want to ask I think Go does not recommend UPPER_SNAKE_CASE since it mostly wants camelCase or PascalCase in variable declaration. (whereas its ok for Java, not sure about Python since it gets angry when not use lower_snake_case) Do you have any thoughts on this?

@yoheimuta
Copy link
Owner

@Dentrax I have no particular thought on the rule's rationality as long as Google and its broad community define it.

In my understanding, proto files' specification is based on a language agnostic policy.
The naming convention for specific languages should be resolved by a compiler and its plugins.

The community has already discussed this topic, so I suggest you check out the link below first.

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

2 participants