Matt, thank you, you took the time to review my code, I appreciate it.
Usually on GitHub the license is in LICENSE, not LICENSE.md <http://license.md/>. Yes, added .md by analogy with README.md <http://readme.md/> core_public.go, transaction_public.go could just be core.go and transaction.go. And I wanted to write core_api.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 I agree, the name is not informative. And the type is undoubtedly overloaded - a too large monolith. Later I'll think of something. Why have errorCodes instead of error? Usually a nil would be returned instead of Ok. Transaction can give an error for different reasons, and I want to give the client a wide choice. Probably, the financial features are to blame for this ... Example: // transaction switch res := tr.Begin().Credit(123, "USD", 5).End(); res { case tn.Ok: fmt.Println("Done! Account cleared") case tn.ErrCodeUnitNotExist: fmt.Println("Unit not exist") case tn.ErrCodeTransactionCatch: fmt.Println("Account not catch") case tn.ErrCodeTransactionCredit: fmt.Println("Such a unit already exists") default: fmt.Println("Unknown error") } I haven’t seen this logging pattern before, interesting. Why not have the go keyword in lgr.log? Replace the word "log" with the word "go"? It seems to me, "log" better reflects the meaning, eh? Also lgr could be an embedded field so you could call c.log instead of c.lgr.log. Good idea! I haven’t seen runtime.Gosched() before but maybe that’s a tool I’ll use sometime. To implement the lock-free algorithm, this is a convenient solution in a situation where the resource is blocked and you have to wait in the loop 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. Still, I want to leave the map to have the keys. I hope that the efficiency of the logger will not be important, since errors will be rare. I hope very much)) Why not “type storage [storageNumber]*section” instead of the struct? True, the locks were gone, but the structure was left ... (( A section and unit could have a *sync.Mutex and then be passed by value instead of by pointer. While they remain structures, as instead of a mutex, there may appear spinlocks or something else. But I did not know about the transfer of mutexes, can you give examples? Is type Account meant to be exported? There are no methods and it’s not used anywhere public. Right, thanks. In your opinion, what level of my code, how would you rate it? Thanks for the detailed and useful review! четверг, 1 февраля 2018 г., 18:16:56 UTC+3 пользователь [email protected] написал: > > Hi Eduard, here’s a code review. > ... > > On Thursday, February 1, 2018 at 2:41:58 AM UTC-6, Claygod wrote: >> >> >> -- 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.
