GENERAL: Use snake_case field names for protobuf messages

[staheri14]

Problem

As suggested by @D4nte: ~~https://github.com/vacp2p/rfc/pull/344/files#r613679908~~ https://github.com/vacp2p/rfc/pull/344#discussion_r613679908 we may want to follow the protocol buffer style guide and use snake_case for field names: https://developers.google.com/protocol-buffers/docs/style

This issue is to get to a consensus re this change. cc: @oskarth @jm-clius Let me know what do you think about it.

[jm-clius]

Yes, I agree. That is the idiomatic way of doing it. Thanks! :)

[oskarth]

Interesting, does this mean what libp2p is doing here with field names like ControlGraft https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md is not really idiomatic? I wonder if we should be idiomatic w.r.t libp2p or protobuf... I suppose this would largely be a stylistic thing more than anything else?

@dryajov @arnetheduck has this been discussed before?

[arnetheduck]

Not that I know - there's a number of these small issues all over libp2p in general, ie assuming field order is deterministic, not following best practices etc.

Probably for any status protocols, it would indeed make sense to follow the style guide (and watch out for protobuf misuse)

[dryajov]

We haven't really implemented a protocol that is not speced out by libp2p and yes it seems like snake_case is more idiomatic, that said I'm not sure if there is any difference besides style?

[D4nte]

One (very small) practical advantage of using the protobuf suggested style in the specs is that developer can just copy paste the code in a proto files and use their favorite generator without getting any warnings and/or errors due to the casing.

[oskarth]

It seems like this is largely a stylistic thing, but I'd be fine with us updating specs across the board be in line with protobuf style guide.

[jimstir]

Closing as issue seems complete.