https://go.dev/doc/effective_go provides a number of conventions that tend to be used (and expected by) the Go community. It looks like this very nice and useful package may use some of that collected wisdom to make itself even more ergonomic and palatable to the Go crowd :-)
For example:
The package name is excessively long. Suggestion: change it to go-nitro, or nitro-attestation
variable, function and constant names should be camel- rather than snake-case
source file naming: lib.go is not where a Gopher would expect to find the package implementation. It's more a Rustacean convention I guess :-)
comments (in particular go doc stuff) should be checked for fitness.
A lot of this tedious stuff is normally flagged by the linter. So, adding a linting step to the CI pipeline usually helps a lot with keeping consistency.
I'd be happy to help with the "apply conventions" pass if you want.
https://go.dev/doc/effective_go provides a number of conventions that tend to be used (and expected by) the Go community. It looks like this very nice and useful package may use some of that collected wisdom to make itself even more ergonomic and palatable to the Go crowd :-)
For example:
go-nitro, ornitro-attestationlib.gois not where a Gopher would expect to find the package implementation. It's more a Rustacean convention I guess :-)A lot of this tedious stuff is normally flagged by the linter. So, adding a linting step to the CI pipeline usually helps a lot with keeping consistency.
I'd be happy to help with the "apply conventions" pass if you want.