Recently I started studying go-ethereum and this was my first time using golang. C++ is my main language and I'm a bit puzzled due to variable names in go-ethereum project.
core/state/managed_state.go:25:type account struct {
core/state/state_object.go:98:type Account struct {
There are both "account" and "Account" types in state package, which seems weird.
I've checked Naming convention for similar Golang variables, and it still looks terrible.
And what I've found is that they use a lot of "Node" struct in different packages. Definitely they do have different purposes and structures.
Are these kinds of naming is convention and popular in golang? If you have any good references for naming convention in golang (e.g. open source projects or books), could you please name some of them? It would be really appreciated.
There are both "account" and "Account" types in state package, which seems weird.
There is a meaningful difference between these two names in the language specification.
From the Go Language Specification:
An identifier may be exported to permit access to it from another package. An identifier is exported if both:
- the first character of the identifier's name is a Unicode upper case letter (Unicode class "Lu"); and
- the identifier is declared in the package block or it is a field name or method name.
All other identifiers are not exported.
So, taking a closer look at the go-ethereum codebase, here are my observations:
I think the implementation choice make more sense when you look at the generated documentation.
In particular, the Account type is front and center, detailing a data structure that's of interest to consumers of the package.
When you look at the documentation for the ManageState struct, the unexported fields are purposely not documented. This is because they're internal details that don't impact the exported interface and could easily be changed without impacting users of the package.
In regards to naming recommendations, see the Names section in Effective Go.