Go lint naming compliance about protobuf HOT 11 CLOSED

It is not an aim for generated code to pass golint.

from protobuf.

For anyone else who see this, it doesn't pass golint unles you structure it like that.
For example

message Args {

    int64 i_d = 1 [json_name="id"];

    string a_p_i_endpoint = 2 [json_name="apiEndpoint"];

}

I add in the json_name specifier so it doesn't turn into iD and aPIEndpoint because json always lowercases the first character. And this way your golang variables look like ID and APIEndpoint, and your json keys will still look clean with id and apiEndpoint

from protobuf.

The problem in my mind isn't with golint of the generated files, it's with code that utlizes generated structs and interfaces.

Code becomes littered with inconsistencies, such as this:

return &service.Response{
  UserId: userModel.ID,
}

from protobuf.

I actually agree. Passing golint here would be a "moving target" for protobuf.

from protobuf.

The problem with such a work around is that now your C/python code is i_d instead of id and Java is iD.

from protobuf.

I think what you probably want is something like #555. That said, perfect golint compliance is a non-goal for generated .pb.go files.

from protobuf.

Maybe it's easier to configure golint to ignore fields from Protocol Buffers?

from protobuf.

While this is easy enough in-file (it just has to match /^\/\/ Code generated .* DO NOT EDIT\.$/) the problem is recognizing that these fields come from a Protocol Buffer when referenced outside of the same file.

As for making golint ignore single lines, or blocks of code rather than whole files, that is a) going to require a change to golint itself, and b) almost certainly would end up being rejected because it goes against a guiding principle that golint should be all-or-nothing. If you’re going to lint a file, then you should lint everything, and not provide an ability to ignore a rule here or there. Either the rule is a good rule, and should be applied everywhere, or it’s a bad rule. (Not necessarily my own philosophy.)

from protobuf.

Correct me if im wrong or saying something completely stupid.... but is this not rather simple to implement?

https://github.com/golang/lint/blob/master/lint.go#L699-L809

If this lintName function inside the golang/lint repo was made public then we could simply pass field names through generator.CamelCase and then through lintName? It could be provided through a flag or something to tell protoc-gen-go to generate golint compliant code to not break existing people.

Example here: https://play.golang.org/p/f8YXDyBsF7W

We have the exact same problem as @dpup. We have mappers from internal definitions of an object to the protobuf representation. So it ends up polluting out actual code as well, not simply the .pb.go files.

What do you thing @dsnet ? gogo/protobuf#691 it seems like this proposal lost traction.

I feel like this solution would also make it simpler and have much less friction than having to explicitly add an option to the proto file.

from protobuf.

Several thoughts:

1. There is no way we can change the name derivation logic today without breaking the world.
2. golint has a hard-coded list of "common" acronyms that has historically been problematic since people can't quite agree what is common or not.
3. golint itself is no longer maintained; see golang/go#38968

from protobuf.

Fair points...

I actually didn't know that golint was now deprecated and I'm actually really sad about that.. For me it was a huge advantage. Having standards/style defined by the community as a whole and the developers of the language other than our company so we don't have to fight over who wants a different style or not. It was also nice to see this as a way of trying to create more consistent code across opensource as well.

Thanks for your feedback though appreciate it!

from protobuf.