go.formatTool: "goimports" and go.formatOnSave: true should be default

[emidoots]

As an almost full-time Go developer since 2012.. There is literally no reason why goimports should not be enabled by default for format-on-save. It is non-risky, does not ever damage code, and unlike many other languages the Go community highly highly encourages one standard format. If this was, C, C++, etc I could understand not enabling a a fmt command by default, but in Go there is literally no risk whatsoever of angering users or modifying code in an undesired way.

/cc @shurcooL because I think he would feel the same way.

[dmitshur]

What is the current default?

I thought the default was to run gofmt on save. Running goimports on save as a default has the consideration that the person may not have goimports command installed.

Also, goimports needs some additional care to be used efficiently. In a poor GOPATH workspace with many, many unrelated packages, suddenly having it on can cause issues. It also requires one to be careful with text/template vs html/template.

I still think it makes a better default for beginners, especially if they have it on from day 1, but I wanted to point out the above concerns.

I think vscode-go might've had some history with auto-save being on by default, which might relevant here.

Edit: See related issues:

• Add format-on-save support (instead of requiring use of explicit Format Document command) #14
• Go fmt on save workflow #30
• Add support for "on the fly compilation" even when Auto Save is off #31

[emidoots]

The current default can be seen in the README.md here: https://github.com/Microsoft/vscode-go#options

I've also verified in my VSCode editor, it is:

"go.formatOnSave": false,

and marked as EXPERIMENTAL too.

I agree that gofmt is generally much faster for large workspaces.. but probably a better default for beginners as you said (advanced users can always configure).

[lukehoban]

We can definitely remove the "EXPERIMENTAL" on formatOnSave.

The one concern with changing the defaults is that some VS Code users like to use AutoSave, which causes the editor to immediately save after a short delay of typing. This is nice for Go because it triggers compile/lint checks automatically.

However, these two features interact imperfectly. Sometimes you pause during typing and gofmt moves code around (or goimports even removes an import you had intentionally just added). It's not unusable, but it is an acquired taste experience.

That said - I think at this point it's probably worth changing the default to have formatOnSave on.

I'm inclined to leave goimports as the default formatter for now - it's easy enough to change if you end up in a situation where it is giving incorrect results.

[ironcladlou]

However, these two features interact imperfectly. Sometimes you pause during typing and gofmt moves code around (or goimports even removes an import you had intentionally just added). It's not unusable, but it is an acquired taste experience.

This is actually maddening and the reason I don't use that setting combo.

[lukehoban]

@ironcladlou Out of curiosity - are you suggesting that we should not turn format-on-save on by default? Or that you don't use auto-save?

[ironcladlou]

@ironcladlou Out of curiosity - are you suggesting that we should not turn format-on-save on by default? Or that you don't use auto-save?

I don't use auto-save, but if I did use auto-save I wouldn't like gofmt to run on auto-save, and would especially not like goimports to run (the annoyance of code reformat under your cursor with the bonus annoyance of import erasing as you described).

I'm neutral towards the defaults given there are options to make everything behave as I like.

[lukehoban]

Got it - great.

Since AutoSave is off by default in Code, and actually now less discoverable, I think it makes sense to tune the defaults to match what works best with that off - which means turning format-on-save on. We can include documentation about the conflict.