On Fri, Apr 24, 2020 at 12: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?
There is a fairly high bar for gofmt changes these days, but it's not
possible. The right approach is to discuss it here, and then if there
is some kind of consensus follow the proposal process outlined at
https://golang.org/s/proposal. Thanks.
One useful metric would be look at some real Go code (that you didn't
write) and how often people use this style. I suspect it's pretty
rare in the standard library. One problem with this style is that (I
think) the argument comments don't show up in godoc, which makes them
hard to discover by people who just want to use the package.
Ian
--
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/CAOyqgcWbF7FUmVG5rhgaipzMG6c-tCZHDETwdHpkh_z5sTSkLQ%40mail.gmail.com.
