Proposal: Allow gofmt to return non-zero if code violations are found

[ryanm101]

What version of Go are you using (go version)?

1.8.3

Does this issue reproduce with the latest release?

Yes

gofmt is a great way to refactor code for developers however in it's current form it requires the developer to actively execute it against their code.

If we add an option to allow gofmt to return a non-zero value if violations are found it would facilitate the integration of it into our build pipelines as we could force builds to fail upon a violation.

This would also reduce the need for 3rd party linting tools such as golint.

[davecheney]

Most folks do this using test -z

…

On 3 Mar 2018, at 22:38, Ryan McLean ***@***.***> wrote: What version of Go are you using (go version)? 1.8.3 Does this issue reproduce with the latest release? Yes gofmt is a great way to refactor code for developers however in it's current form it requires the developer to actively execute it against their code. If we add an option to allow gofmt to return a non-zero value if violations are found it would facilitate the integration of it into our build pipelines as we could force builds to fail upon a violation. This would also reduce the need for 3rd party linting tools such as golint. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ryanm101]

I'm not overly experienced with GO but running "go test -z" does nothing for me even once I put in a badly indented line

[mvdan]

Dave likely meant something like test -z $(gofmt -l your-dir). That checks if there are zero files that gofmt would modify.

[ryanm101]

lol.. of course. I thought there was a go specific command :)

[davecheney]

Yup, that’s what I was trying to say. Sorry for not being more specific.

…

On 4 Mar 2018, at 03:18, Ryan McLean ***@***.***> wrote: lol.. ofcourse. I thought there was a go specifc comman :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[magical]

Possibly worth noting that this sort of thing is discouraged by the go team:

Note that these kinds of minor updates to gofmt are expected from time to time. In general, we recommend against building systems that check that source code matches the output of a specific version of gofmt. For example, a continuous integration test that fails if any code already checked into a repository is not “properly formatted” is inherently fragile and not recommended.

[davecheney]

I find this advice misleading as the CI process that we use on build.golang.org specifically applies this check.

…

On 5 March 2018 at 12:49, Andrew Ekstedt ***@***.***> wrote: Possibly worth noting that this sort of thing is discouraged <https://golang.org/doc/go1.10#gofmt> by the go team: Note that these kinds of minor updates to gofmt are expected from time to time. In general, we recommend against building systems that check that source code matches the output of a specific version of gofmt. For example, a continuous integration test that fails if any code already checked into a repository is not “properly formatted” is inherently fragile and not recommended. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24230 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcAxssDTNpgm2NrSyTvHS-Tc2Sjttnks5tbJmYgaJpZM4Sa4v_> .

[dmitris]

FWIW we always fail the builds in our CI system if gofmt violations are found - that really helps to have the consistent codebase and is very effective in getting engineers new to Go or to the company used to properly format the code. It also prevents having non-compliant files from accumulating in the codebase. So far we haven't seen any problems with gofmt changes leading to fragility etc, adn go1.9 to go1.10 transition was OK. (We did see several failures due to https://golang.org/doc/go1.10#test-vet but those got quickly fixed)

[rsc]

As @mvdan said, you can already check whether the output of gofmt -l is empty. Please do that. That's more than one bit anyway.