I think that these are independent questions. While I agree entirely with
your comments on avoiding lots of parameters, and bundling them in a struct
if it gets out of hand, helping clarity is of value whether no matter how
many arguments there are. By analogy:
var aStructList = []*SomeStruct {
{
FieldName: "SomeName", // Comment for FieldName
Value: 12, // Comment for Value
},
}
and
var aStructList = []*SomeStruct {
// Comment about the following entry
{ FieldName: "SomeName", Value: 12 },
}
or
var aStructList = []*SomeStruct {
{ FieldName: "SomeName", Value: 12 }, // Comment about the entry on
this line
}
are both perfectly fine (aren't they?).
On Friday, April 24, 2020 at 4:15:46 PM UTC-4, Saied Seghatoleslami wrote:
>
> 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 <[email protected]
> <javascript:>> 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 [email protected] <javascript:>.
>> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/3a0222c1-2063-4c64-a828-40e8e689ba33%40googlegroups.com.
