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.
