"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.
