Doesn't this style of writing assume that there are a lot of arguments to
be passed to function which I think is not a good practice since it makes
it much harder to remember what the function does and how to call and most
importantly, how to debug it when becomes necessary?

So, if there are a lot of arguments to be passed to the function, it is
best to redesign it and use a data structure that encapsulates the
arguments.  Otherwise, what is wrong with this?


// Great is a really great function anArg does this and anotherArg does
that.
func Great(anArg int, anotherArg string) (err error) {
return nil
}

On Fri, Apr 24, 2020 at 3:32 PM Scott Deerwester <scott.deerwes...@gmail.com>
wrote:

> I greatly appreciate the fact that Go has a coding standard. I have a
> modest proposed modification. Instead of this:
>
>     // Great is a really great function.
>     func Great(
>         anArg int, // This explains anArg
>         anotherArg string, // This explains anotherArg
>     ) (err error) {
>     ...
>
> I'd think that this:
>
>     // Great is a really great function.
>     func Great(
>         anArg      int,    // This explains anArg
>         anotherArg string, // This explains anotherArg
>     ) (err error) {
>     ...
>
>
> would be both clearer and more consistent with this:
>
>     var (
>         aVar       = 12          // This explains aVar
>         anotherVar = "something" // This explains anotherVar
>     )
>
>
> or this:
>
>     type SomeStruct struct {
>         FieldName string
>         Value     int
>     }
>
>
>     var aStructList = []*SomeStruct {
>         {
>             FieldName: "SomeName", // Comment for FieldName
>             Value:     12,         // Comment for Value
>         },
>     }
>
> which are already part of the standard coding style. Is this the right
> place to make such a proposal?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8a4fa305-a8bc-4512-8f23-6a42b479dd2d%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/8a4fa305-a8bc-4512-8f23-6a42b479dd2d%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOdwK1k%3DFf82EG91njLq37ybvQZA_Hq0KmPBG%2B1FW_CYF3h1Xg%40mail.gmail.com.

Reply via email to