Zig naming conventions

[42LM]

Hey folks, while working on #78 i happened to see that there is different function naming conventions in the project.

Currently the project uses 2 different styles for function names snake_case and camelCase. My suggestion is to pick one of them and stick to it. If my eyes do not trick me this is the only thing that needs to be adjusted.

https://github.com/Arwalk/zig-protobuf/blob/e25f02777c84183fd7f793afbb7b2f33ccd237cf/src/protobuf.zig#L57

https://github.com/Arwalk/zig-protobuf/blob/e25f02777c84183fd7f793afbb7b2f33ccd237cf/src/protobuf.zig#L139

Official ziglang docs mention the following:

"Roughly speaking: camelCaseFunctionName, TitleCaseTypeName, snake_case_variable_name."

For more info: https://ziglang.org/documentation/0.13.0/#Names

---

WDYT? In the end i do believe sticking to the common style is a good idea (That would mean changing snake_case funcs to camelCase).

[Arwalk]

I was sure an issue on this was already created but apparently not. Thanks. We should stick to the official naming conventions, as they are used in the STD and debates about styles are pointless, whatever anyone's taste.

Changing the function names will invariably lead to API changes here, so this would be a 3.0.0 release. Either we push it into the next feature release https://github.com/Arwalk/zig-protobuf/milestone/2 and make it a 3.0.0, or we actually keep it for 3.0.0 https://github.com/Arwalk/zig-protobuf/milestone/1

I'd like to avoid making another major release too soon personally, but i'm all ears for opinions.

[42LM]

First of all I totally agree with not pushing for a major release soon.

I do not know the project and all it's issues by heart already, but i can already think of one thing:

In #87 we could move over to the new file with the correct syntax already. It would make sense to split creating the new file for the json parsing logic and using it in the protobuf.zig. Implementing the switch could also contain the func naming changes than.

So i think it is good to place it in the actual milestone v3.0.0 and not rush anyhting here 😇.

[Arwalk]

I see that we agree. Overall i'd prefer to freeze anything that's not an actual bug until Zig's 0.14 release, then we'll be able to progress on some of the tickets in the milestones.

[mnemnion]

It might make sense to offer the new names in a minor release, then deprecate the old names with @compileError in the major. Helps spread the impact out a bit.

[Arwalk]

It might make sense to offer the new names in a minor release, then deprecate the old names with @compileError in the major. Helps spread the impact out a bit.

Good point. I wonder if we can find examples of deprecated functions in the zig library and take inspiration of how it was done.