Hi Eduard, here’s a code review. Usually on GitHub the license is in LICENSE, not LICENSE.md.
core_public.go, transaction_public.go could just be core.go and transaction.go. The Core type is a code smell to me because it doesn’t represent anything specific. Perhaps there’s a need for multiple concurrent Cores. The type seems overloaded to me. Why have errorCodes instead of error? Usually a nil would be returned instead of Ok. I haven’t seen this logging pattern before, interesting. Why not have the go keyword in lgr.log? Also lgr could be an embedded field so you could call c.log instead of c.lgr.log. I haven’t seen runtime.Gosched() before but maybe that’s a tool I’ll use sometime. The logger may be more efficient as a slice. As a map you don’t need to hold a pointer to it in Core (maps are represented as a pointer value). For send() the %v printf formatter makes the type switch unnecessary. Why not “type storage [storageNumber]*section” instead of the struct? A section and unit could have a *sync.Mutex and then be passed by value instead of by pointer. Is type Account meant to be exported? There are no methods and it’s not used anywhere public. Matt On Thursday, February 1, 2018 at 2:41:58 AM UTC-6, Claygod wrote: > > Hi! > > I'm writing a small library for transactions with accounts. > Designed for multi-thread use, and I hope it's quite productive. > Link to Githab: https: //github.com/claygod/transaction > I will be grateful for the feedback. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
