Well said! Still I prefer functions to comments, when possible. As it's been said, code never lies, comments sometimes do. And a boom is simpler to understand (for me). Functions go boom; comments do not.
On Saturday, August 12, 2017 at 1:48:05 AM UTC+4:30, Egon wrote: > > 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.
