Ian's and Lutz's responses get to the heart of how comments on parameters
are different from comments on struct field, constant and variable
initializations, namely that the documentation framework (whether in an IDE
or via godoc) elevates comments on functions to a different status than
"inter
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 e
On Fri, Apr 24, 2020 at 12:32 PM Scott Deerwester
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
>
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 {
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
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) {
..
