There are no good things... only trade-offs. Clarity is not directly about naming, but rather balancing locus of attention and working memory. When you put too many things together (such as a long function), you fill up your short term memory when reading the code... on the other side, when you make too many pieces you have to constantly switch from one piece to another to understand something. But yes, good names enable learning chunks and make recalling easier.
So yeah... you want balance between these two aspects... though people have different strengths -- e.g. some people have better working memory and some have better focus switching skills... I suspect this what leads some people to prefer one style over the other. On Friday, 11 August 2017 22:12:09 UTC+3, dc0d wrote: > > 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.
