Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/gofmt: formatting of struct literal depends inconsistently on lengths of field names #7335

Closed
cloneable opened this issue Feb 14, 2014 · 5 comments
Assignees

Comments

@cloneable
Copy link

@cloneable cloneable commented Feb 14, 2014

http://play.golang.org/p/UlzyF8U_nZ

func main() {
    z := MyStruct{
        Foo:      "foo",
        Bar:      "bar",
        Name:     "name",
        LongName: "longname",
        Baz:      "baz",
    }
    y := MyStruct{
        Foo:                   "foo",
        Bar:                   "bar",
        NameXX:                "name",
        LongNameXXXXXXXXXXXXX: "longname",
        Baz: "baz",
    }
    z := MyStruct{
        Foo:  "foo",
        Bar:  "bar",
        Name: "name",
        LongNameXXXXXXXXXXXXX: "longname",
        Baz: "baz",
    }
}
@robpike
Copy link
Contributor

@robpike robpike commented Feb 15, 2014

Comment 1:

Labels changed: added repo-tools.

Owner changed to @griesemer.

@robpike
Copy link
Contributor

@robpike robpike commented Feb 15, 2014

Comment 2:

Status changed to Accepted.

@cloneable
Copy link
Author

@cloneable cloneable commented Feb 16, 2014

Comment 3:

What's the expected output for (2) and (3)?
(2) looks like a bug, but I could see (3) as an optimization where alignment is broken
up into two groups due to a long field name in-between. However, I couldn't find test
input for this in testdata/. So this is a bug as well?
@griesemer
Copy link
Contributor

@griesemer griesemer commented Feb 18, 2014

Comment 4:

This is working as intended.
There is explicit code to check for large size discrepancies of keys in composite
literals, see: http://golang.org/src/pkg/go/printer/nodes.go#L195
In short, if the difference in size between two adjacent keys is more than a factor of
4, the alignment is broken. This avoids values aligned all the way to the far right in
very large composite literals simply because one key somewhere is very long. It's a
heuristic alright, and the factor (4) can be debated, but it's been working reasonably
well so far.
In this specific case, NameXX has length 6, LongNameXXXXXXXXXXXXX has length 21, and 4*6
> 21, so they is no break of alignment. Name has length and thus the difference between
LongNameXXXXXXXXXXXXX and Name is more than a factor of 4, and then the alignment is
broken. Same holds for LongNameXXXXXXXXXXXXX and Baz.

Status changed to WorkingAsIntended.

@griesemer
Copy link
Contributor

@griesemer griesemer commented Feb 18, 2014

Comment 5:

Let me rephrase the last paragraph correctly:
In this specific case, NameXX has length 6, LongNameXXXXXXXXXXXXX has length 21, and 4*6
> 21, so there is no break of alignment. Name has length 4 and thus the difference
between LongNameXXXXXXXXXXXXX and Name is more than a factor of 4, and then the
alignment is broken. Same holds for LongNameXXXXXXXXXXXXX and Baz.
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.