Thanks for suggesting guru. I'll try it. If there is a convention for naming, it makes code more clear, otherwise, yes, it makes code more unclear - in my experience. In times it's not an easy task. But having a long function too, is not a good thing (IMHO).
On Friday, August 11, 2017 at 6:02:31 PM UTC+4:30, Egon wrote: > > Note, this can fragment the code and make it harder to understand... ( > http://number-none.com/blow/john_carmack_on_inlined_code.html) > > As for the tool: > > guru can give you the callers of a function, so you might be able to > derive something from it. > > + Egon > > On Friday, 11 August 2017 10:39:16 UTC+3, dc0d wrote: >> >> "When you feel the need to write a comment, first try to refactor the >> code so that any comment becomes superfluous." >> - Martin Fowler, Kent Beck, John Brant, William Opdyke, and Don Roberts >> (1999) Refactoring: Improving the Design of Existing Code. Addison-Wesley. >> >> Based on this practice, the code below (this code's sole purpose is to >> demonstrate): >> >> func sampleSloppyFuncForDescribingThisSpecificProblem(data *Data, p *DLO) >> error { >> if !isNameOK(data.FirstName, data.MiddleName, data.LastName) { >> return errInvalidName >> } >> >> if !isAddressOK(data.Address1, data.Address2) { >> return errInvalidAddress >> } >> >> if !isPhoneOK(data.PhoneNumber, data.MobileNumber) { >> return errInvalidPhone >> } >> >> p.Address1 = data.Address1 >> p.Address2 = data.Address2 >> p.BirthDate = data.BirthDate >> p.FirstName = data.FirstName >> p.LastName = data.LastName >> p.MiddleName = data.MiddleName >> p.MobileNumber = data.MobileNumber >> p.PhoneNumber = data.PhoneNumber >> >> return nil >> } >> >> Can get refactored to (instead of adding comments): >> >> func sampleSloppyFuncForDescribingThisSpecificProblem(data *Data, p *DLO) >> error { >> if err := validateData(data); err != nil { >> return err >> } >> >> transferData(data, p) >> >> return nil >> } >> >> func validateData(data *Data) error { >> if !isNameOK(data.FirstName, data.MiddleName, data.LastName) { >> return errInvalidName >> } >> >> if !isAddressOK(data.Address1, data.Address2) { >> return errInvalidAddress >> } >> >> if !isPhoneOK(data.PhoneNumber, data.MobileNumber) { >> return errInvalidPhone >> } >> >> return nil >> } >> >> func transferData(data *Data, p *DLO) { >> p.Address1 = data.Address1 >> p.Address2 = data.Address2 >> p.BirthDate = data.BirthDate >> p.FirstName = data.FirstName >> p.LastName = data.LastName >> p.MiddleName = data.MiddleName >> p.MobileNumber = data.MobileNumber >> p.PhoneNumber = data.PhoneNumber >> } >> >> Now the sole purpose of functions validateData and transferData is >> providing a clean and more descriptive code. They should appear only in one >> place in the code inside the body of >> sampleSloppyFuncForDescribingThisSpecificProblem. This is what I need to >> check. >> >> On Friday, August 11, 2017 at 8:57:46 AM UTC+4:30, Henry wrote: >>> >>> I don't fully understand the problem, but if you need a quick and dirty >>> way to ensure a function is called exactly once, you can always use a >>> global variable, have the function checks the variable when the function is >>> called. If the function is called the first time, it will set the variable. >>> If the function has been called more than once, it should panic and returns >>> the stacktrace. >>> >>> On Friday, August 11, 2017 at 3:02:47 AM UTC+7, dc0d wrote: >>>> >>>> Is there a tool/linter to check if a private package function gets >>>> called exactly once *in the code*? (I'm not looking for a runtime >>>> solution like *sync.Once* but a code analysis tool/linter). >>>> >>>> Purpose: A guideline on commenting code by Martin Fowler states that >>>> before writing a comment, see if it is possible to put that part inside a >>>> meaningful function. I've followed that guideline for sometime and it >>>> helps >>>> to have a cleaner code base. But those explanatory functions should get >>>> called only from where that they are meant to make it more clear. >>>> >>> -- 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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
