-
-
Notifications
You must be signed in to change notification settings - Fork 112
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
use more newlines when formatting very complex composite literals #104
Comments
What was the original input to gofumpt? I definitely agree that the code as shown is pretty hard to read, but gofumpt also tries to obey the formatting choices in the original code in some cases. |
Ah okay, that makes sense, I had a slight hunch this might be the case. I think it's reasonable to close this issue then. The input in the issue description came after some other mutations I was trying, the most original (generated) input I had was this, which should be formatted nicely after #70:
|
I think "generate all code in very few lines and let gofumpt pretty-print it however it wants" is a valid use case, so I'd leave this issue open. It does have a big overlap with breaking long lines, so I'd like to tackle that first, but once that's done then we can use this issue to see what else we could do for generated code. |
Thinking outloud a bit, I think we should enforce more newlines when there are many (e.g. more than 2) levels of composite literals starting or ending on a single line. I think However, if there is just a couple of levels, I think it's entirely reasonable. For example:
|
Cool, that sounds fair, I like your thought above, that sounds like a great reduction in the problem space here down to something tangible. In fact, I think even if just "composite literals >2 deep ending on a single line" were the case, the code in the issue description would be much better (though I certainly have a strong preference for both starting and ending on a single line): v := [2]interface{}{&st.Query{DocTypes: &st.DocTypes{CST: &st.DocTypesCST{
List: &st.DocTypesListCST{
Name: "foo", Separator: ",",
Next: &st.DocTypesListCST{Name: "bar"},
},
}}, Expr: &st.QueryExpr{Logical: &st.ExprLogical{Or: &st.ExprLogicalOr{
Left: st.QueryExpr{Default: &st.ExprDefault{Terms: "not implemented"}},
Right: st.QueryExpr{Default: &st.ExprDefault{Terms: "not implemented"}},
}},
}}, nil} |
Hoping to resurrect this request, since I really need this feature as well for generated code. Example of before and (desired) after. func (Activity) Fields() []ent.Field {
return []ent.Field{field.String("title").Optional(), field.String("dateRange").Optional(), field.String("location").Optional(), field.Int("groupId").Optional().Immutable()}
} Desired formatting: func (Activity) Fields() []ent.Field {
return []ent.Field{
field.String("title").Optional(),
field.String("dateRange").Optional(),
field.String("location").Optional(),
field.Int("groupId").Optional().Immutable(),
}
} The second is way easier to read than the first. UPDATE: |
(huge thank you for gofumpt, BTW, it's awesome!)
I have lots of code similar to this which I am generating and then formatting with
gofumpt
:My primary readability gripes here are:
Expr:
field is under (line}}, Expr: &st.QueryExpr{Logical: &st.ExprLogical{Or: &st.ExprLogicalOr{
)nil
value of the[2]interface{}
array. When reviewing these where the 2nd array value is notnil
but rather a&Foobar{}
struct value, they blur together a bit for me.I can think of a few improved formattings which seem more easily readable to me, including:
&st.Query
, using trailing commas on e.g.nil
: https://gist.github.com/slimsag/b92e8f1e82f33afa5d075c14578a41b7I understand gofumpt is more opinionated, though, and I'm not too attached to the exact formatting improvements here - I am just more broadly asking what improvements seem reasonable here such that gofumpt could make this code more readable potentially
The text was updated successfully, but these errors were encountered: