Since we don't have a mailing list (not saying we need one) I'd like to discuss here a few style changes:
- when naming a method that simply returns Foo, name it Foo() instead of GetFoo().
~ GetFoo() is currently common in the code, but one example: item.GetPosition()
- interfaces should be named ISomething, as is the case in interface.go
~ there are a few exceptions, but we should probably normalize this.
- should we have a guideline for when a method should return a reference or a value? It feels a bit confusing at the moment. We could be tempted at always returning references, but that's unsafe. Literature like "Code Complete" point out that this is a common source of bugs, since the caller obviously can change the value and this is not always what we want. At the same time, it's argued that the possible performance gains are hard to notice.
~ an option is to always return by value unless not possible. But I feel a bit bad in copying values around, so I honestly don't know what's best. I just miss having some consistency.
~ All that said, if we settle down with some kind of pure-channel design where only a single goroutine has access to an object, we could stick to a "always return by reference" rule.
Since we don't have a mailing list (not saying we need one) I'd like to discuss here a few style changes:
~ GetFoo() is currently common in the code, but one example: item.GetPosition()
~ there are a few exceptions, but we should probably normalize this.
~ an option is to always return by value unless not possible. But I feel a bit bad in copying values around, so I honestly don't know what's best. I just miss having some consistency.
~ All that said, if we settle down with some kind of pure-channel design where only a single goroutine has access to an object, we could stick to a "always return by reference" rule.