As he cleared up in his later quotes and tweets it's about replacing
comments with functions. IMHO this way comments will turn into active
(code) specifications and would help greatly specially in a statically
types languages. They might even make writing more clear tests easier. But
(IMHO) having more functions does not necessarily means having better
reusable code.
In this case the functions in question are *private* functions in a package
and their sole purpose is to replace comments in another (one specific)
function.
On Friday, August 11, 2017 at 4:43:29 PM UTC+4:30, Henry wrote:
>
> I am not aware of any such tools exist. You may need to roll out your own.
>
> However, don't you think that the purpose of Fowler,et al. proposing such
> guideline is to encourage function reuse?
>
> On Friday, August 11, 2017 at 2:39:16 PM UTC+7, 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.
