-
-
Notifications
You must be signed in to change notification settings - Fork 113
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
Remove empty lines in if and for similar to functions #284
Comments
We already have the following rules:
What extra rules would you add, exactly? I personally think that anything more than this would make gofumpt too aggressive. Empty lines can be good to logically separate bits of code. |
First, thank you for this swift response! I'm proposing to add if and for statements to the function rule. It makes code more regular about empty lines. I do agree empty lines are good to separate bits of code. My point is exactly about lines after opening curly bracers
This addition would produce the following effects (comments where to remove empty lines): func main() {
somethingSomething()
for i := 0; i < 5; i++ {
// REMOVE: No empty lines around *for* bodies
err := doSomething()
if err != nil {
// REMOVE: No empty lines around *if* bodies.
go reportError()
fmt.Println(err)
// REMOVE: No empty lines around *if* bodies.
}
go codeKeepsGoingOn()
doAnotherThingVoid()
// REMOVE: No empty lines around *for* bodies
}
somethingSomething()
} this behavior would produce the following final code: // my proposal
func main() {
somethingSomething()
for i := 0; i < 5; i++ {
err := doSomething()
if err != nil {
go reportError()
fmt.Println(err)
}
go codeKeepsGoingOn()
doAnotherThingVoid()
}
somethingSomething()
} |
Currently gofmt already removes empty lines around
type A interface {
// This line is removed
Something() bool
Sometime() time.Time
// This line is removed
}
type b struct {
// This line is removed
id int
name string
// This line is removed
} And gofumpt currently removes around |
I support the proposed change to remove blank spaces after open brackets and before closing brackets. In my opinion, this change would not degrade the code readability and would make it more concise with fewer inconsistencies. I appreciate the effort put into improving the code formatter behavior and believe that this change would be a positive step forward. |
If you're looking for another reason to support this change, the whitespace linter complains about these kinds of newlines; having |
I also support this proposal. I don't mind defining it as two new rules:
However, I think if we want to be succinct, the rule that we actually want is This would apply to scopes created by func Something() {
{
fmt.Println("hello")
}
{
fmt.Println("world")
}
} becomes: func Something() {
{
fmt.Println("hello")
}
{
fmt.Println("world")
}
} |
I totally agree @davidmdm |
Isn't this a regression? or I'm just wrong? |
@cristaloleg please expand? It can be viewed as two new rules or an expansion on an existing rule. It would not perform invalid formatting as per gofmt. |
I thought that if err != nil {
fmt.Println(err)
} was formatted to if err != nil {
fmt.Println(err)
} I might be wrong or something else changed in my local setup. |
@cristaloleg I used a very simple example just to show what I intended. I tested if and yes, if you have only one instruction inside the
|
@mvdan any input? I created a PR that seems to accomplish the goal. |
I took a brief look at this. In some cases I agree this removes empty lines which aren't necessary, but in other cases it removes empty lines which I find useful to logically separate different chunks of code. For example, in a project of mine: diff --git a/syntax/printer.go b/syntax/printer.go
index 7c3ff9e6..ba1e6c29 100644
--- a/syntax/printer.go
+++ b/syntax/printer.go
@@ -62,7 +62,6 @@ func KeepPadding(enabled bool) PrinterOption {
p.keepPadding = true
p.cols.Writer = p.bufWriter.(*bufio.Writer)
p.bufWriter = &p.cols
-
} else if !enabled && p.keepPadding {
// Ensure we reset the state to that of NewPrinter.
p.keepPadding = false
@@ -1496,7 +1495,6 @@ func (e *extraIndenter) WriteByte(b byte) error {
e.firstIndent = lineIndent
e.firstChange = e.baseIndent - lineIndent
lineIndent = e.baseIndent
-
} else if lineIndent < e.firstIndent {
// This line did not have enough indentation; simply indent it
// like the first line.
diff --git a/syntax/typedjson/json_test.go b/syntax/typedjson/json_test.go
index 5292fa7c..53b1c773 100644
--- a/syntax/typedjson/json_test.go
+++ b/syntax/typedjson/json_test.go
@@ -26,7 +26,6 @@ func TestRoundtrip(t *testing.T) {
shellPaths, err := filepath.Glob(filepath.Join(dir, "*.sh"))
qt.Assert(t, err, qt.IsNil)
for _, shellPath := range shellPaths {
-
shellPath := shellPath // do not reuse the range var
name := strings.TrimSuffix(filepath.Base(shellPath), ".sh")
jsonPath := filepath.Join(dir, name+".json") The first two don't seem right to me - I want to split the "else if", much like I might do with different cases in a switch. You might prefer to not use that empty line yourself, but I don't think that falls under "an empty line there is definitely pointless and gofumpt should remove it". I'd be fine with strenghtening this rule as long as it leaves empty lines at the end of blocks followed by an else-if. All other removed lines I can see across my projects seem fine to me. Happy to review a PR with the above tweak as well as tests for all the various edge cases; note that #286 has no tests and so it isn't enough on its own. Look at The README would also need to be tweaked, but I can do that after the change is merged. |
ensures that format removes empty lines at the top of a block unconditionally and bottom unless it is followed by an else-if statement. see issue mvdan#284
ensures that empty line before an else-if statement is not removed. see mvdan#284.
see mvdan#284. trailing empty lines are removed only if it is not followed by an else-if statement.
would become
my proposal is to remove same empty lines in
if
andfor
statement as wellnote that the empty lines between different instructions in same level doesn't get removed. Same way as empty lines between function declarations.
this behavior is more consistent and better to read.
The text was updated successfully, but these errors were encountered: