4 ms·
I mostly avoid getters/setters in Go code, unless I have a lot of functions all related to the same thing similarly named. It's the return type that denotes th
by Zamicol 4y ago
I mostly avoid getters/setters in Go code, unless I have a lot of functions all related to the same thing similarly named. It's the return type that denotes the return. It's already in the function signature.
That advice is a consequence of Go expecting function signatures to be read and understood. That's not the right choice for all programming languages, but for Go it works.
- throwaway2203 4y agoI mean, you can't get around database CRUDs. I'm not talking about setting a private variable and getting or setting it (that doesn't seem like idiomatic Go at all), but using the logic described above, you can't know whether a method with a noun-based name is a Read or a Create.
- euroderf 4y agoShouldn't a Create have the form NewBlah ? Incidentally warning that there is a memory allocation.
- robertlagrant 4y ago> I mostly avoid getters/setters in Go code, unless I have a lot of functions all related to the same thing similarly named. It's the return type that denotes the return. It's already in the function signature. But I thought Golang doesn't have function overloading, so you also have to name the function appropriately for its use?
- throwaway2203 4y agoYupppp. But you can't let function names get too long or everyone will laugh at you for being a Java dev writing Go. Like I said, absurd.