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: remove -tabs and -tabwidth flags #7101

Closed
bradfitz opened this issue Jan 10, 2014 · 18 comments
Closed

cmd/gofmt: remove -tabs and -tabwidth flags #7101

bradfitz opened this issue Jan 10, 2014 · 18 comments
Milestone

Comments

@bradfitz
Copy link
Contributor

Go indent style is tabs.

The gofmt command-line tool misleadingly advertises the ability to customize the ident
behavior with -tabs and -tabwidth, but then that is no longer gofmt'd code. The proper
Go style way to do this is to configure your editor's display of tabs instead.

I think we should remove those two flags from cmd/gofmt.  (not from the go/* packages)

The Go 1 compatibility promise excludes the tools.

Users who really care can write their own formatter binary using go/format or
go/printer, but it won't be gofmt.
@minux
Copy link
Member

minux commented Jan 10, 2014

Comment 1:

I support this change.

@griesemer
Copy link
Contributor

Comment 2:

Labels changed: added repo-main.

Owner changed to @griesemer.

@minux
Copy link
Member

minux commented Jan 10, 2014

Comment 3:

another benefit of adjust editor tabstop setting is that other gofmt'ed code
automagically looks right, instead of just your code looks right to you.
if we make this change, we probably should add an FAQ entry about this.

@gopherbot
Copy link
Contributor

Comment 4 by dskloet:

I'm only starring because I want to receive updates. Please don't count my star as
support.

@cespare
Copy link
Contributor

cespare commented Jan 10, 2014

Comment 5:

I have a patch at https://golang.org/cl/50600043. I'll mail if we reach
consensus.
Please count my star as support.

@davecheney
Copy link
Contributor

Comment 6:

Provided that the tabs functionality on go/fmt is tested, so we don't break it on people
who write their own code formatters -- that would be rubbing salt into the wound, then
SGTM.

@4ad
Copy link
Member

4ad commented Jan 10, 2014

Comment 7:

I support this. -tabs is pointless. Gofmt correctly uses tabs for indentation and spaces
for alignment, so Go code looks correct with any tab width setting.

@dmitshur
Copy link
Contributor

Comment 8:

I support this change.
It has benefits of making .go files more uniform, and the flexibility of displaying
different tab widths is shifted over to the text editor (where it already exists, and
belongs).

@gopherbot
Copy link
Contributor

Comment 9 by dskloet:

How would it make .go files more uniform?
It would just drive some people away from using gofmt.

@minux
Copy link
Member

minux commented Jan 11, 2014

Comment 10:

always using tab is more uniform that some using tabs, and some using spaces (and worse
yet,
there are different settings of -tabwidth).
IMO, not using gofmt simply means driving away potential users of the package.
(I, for example, won't use a package if it hasn't been gofmt'ed.)

@kisielk
Copy link
Contributor

kisielk commented Jan 11, 2014

Comment 11:

I'm +1 for the change. The purpose of gofmt is to put code in to the canonical Go style,
which is indented with tabs. There's no reason to provide options to put it in to
another style, it just serves to confuse new users.
If someone wants to format Go code in to their own style, they can easily create their
own tool by forking the gofmt code.

@gopherbot
Copy link
Contributor

Comment 12 by dskloet:

That may be true. But how does removing functionality from gofmt change that? You think
people who prefer space will suddenly change their mind because gofmt gives them the
finger?

@dominikh
Copy link
Member

Comment 13:

Having the options suggests, to new users, that using them is fine and that they're
still following Go style even though they're not.
Not having them is more likely to get new people to adopt the correct style. The select
few who are stubborn enough to ignore the style are free to go through the hassle of
using their own fork of gofmt.

@gopherbot
Copy link
Contributor

Comment 14 by divoxx:

Yes, because gofmt is adopted and perceived by the community as a requirement. Most
people won't contribute to projects that are not gofmt'ed properly. Go programmers
*love* the fact that gofmt is the defacto standard and they follow it. Usually, people
that are doing something different are new to the language and too attached to their
other language's standards.

@minux
Copy link
Member

minux commented Jan 11, 2014

Comment 15:

they probably won't change their mind just because this change.
but I sincerely hope they change their mind at least for Go (and I know people
who did)
as I said in the mailing discussion, Go is a language optimized for read rather
than write, and having consistent formatting is just one aspect of it.

@cespare
Copy link
Contributor

cespare commented Jan 11, 2014

Comment 17:

@Dave (comment #6)
If you're referring to the go/format package, that currently only provides functionality
for the canonical style (with tabs).
You'd have to reimplement gofmt using other go/* packages and turn TabIndent off in
go/printer. Looking at the tests for that package, it appears that it actually does not
use TabIndent for the test cases.

@dsymonds
Copy link
Contributor

Comment 18:

I don't think discussion on this bug is going to get anywhere productive. It's the same
viewpoints over and over again. Let's leave it with Robert.

Labels changed: added restrict-addissuecomment-commit, controversial.

@bradfitz
Copy link
Contributor Author

Comment 19:

This issue was closed by revision 014f3dc.

Status changed to Fixed.

@golang golang locked and limited conversation to collaborators Dec 8, 2014
@rsc rsc added this to the Go1.3 milestone Apr 14, 2015
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests