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: does it have to specify tab width = 8 ? #19618

Closed
bits01 opened this issue Mar 20, 2017 · 8 comments
Closed

cmd/gofmt: does it have to specify tab width = 8 ? #19618

bits01 opened this issue Mar 20, 2017 · 8 comments

Comments

@bits01
Copy link

@bits01 bits01 commented Mar 20, 2017

https://tip.golang.org/cmd/gofmt/

Gofmt formats Go programs. It uses tabs (width = 8) for indentation and blanks for alignment.

Does it need to specify tab width = 8? If not, could you please remove it?

@mvdan
Copy link
Member

@mvdan mvdan commented Mar 20, 2017

Perhaps this has something to do with padding of comments, assignments and key-value pairs, since those are done with spaces.

@mvdan
Copy link
Member

@mvdan mvdan commented Mar 20, 2017

@bradfitz bradfitz added this to the Go1.9 milestone Mar 20, 2017
@griesemer
Copy link
Contributor

@griesemer griesemer commented Mar 20, 2017

@bits01 Tabs are only used for indentation. Their width determines how many blanks are required for alignment of comments and other things (after indentation). Since the tab width is fixed, it makes sense to mention it because for an editor to display source properly aligned (as formatted by gofmt), that editor needs to know that the tab with needs to be set to 8. Furthermore, some editors/users have tabs replaced with blanks, and that number of blanks should match tab width.

Originally, tab width could be changed (it was a flag rather than a constant). However, in practice that only caused problems because different people would gofmt source differently. Also, in practice, tab with is unchanged for most people and set to 8. One of the benefits of gofmt is not just visual; by reducing variability of formatting it reduces merge conflicts and other spurious differences when reviewing code.

I'm going to close this. Feel free to re-open if you feel you have a strong reason as to why it shouldn't be mentioned. Thanks.

@griesemer griesemer closed this Mar 20, 2017
@bits01
Copy link
Author

@bits01 bits01 commented Mar 20, 2017

Thanks for your reply. I'm still not sure I understand. I thought the reason for using tabs was to let people decide in their editor how big the indent is in terms of spaces, e.g. users could set their editor tab width to 2, 4, 8 or whatever they like. It also seems that editors tend to default tab width to 4 not 8.

If the code formatted by gofmt "looks good" only when tab width = 8, then shouldn't the tool simply use 8 spaces instead of tabs and not mix tabs and spaces?

I am not trying to open the tabs vs spaces can of worms, just trying to understand the rationale behind the decision to document the tab width.

Thank you.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Mar 20, 2017

@griesemer, I think we should keep this open to fix the wording, as this keeps coming up.

Putting "(width = 8)" after the word "tabs" is what's confusing people.

Instead of:

Gofmt formats Go programs. It uses tabs (width = 8) for indentation and blanks for alignment.

We could write something like:

Gofmt formats Go programs. It uses tabs for indentation and spaces for alignment of comments, assuming a tab width of 8.

(Or more or less verbose, at your choosing.)

@mvdan
Copy link
Member

@mvdan mvdan commented Mar 20, 2017

I think @bradfitz's suggestion makes it much clearer without being verbose. I assume we don't want to get into historical details there.

@bits01
Copy link
Author

@bits01 bits01 commented Mar 20, 2017

@mvdan we do not and the purpose is not to try to change what gofmt does in any way. As @bradfitz said, the statement should sound more like a suggestion, e.g.

For best readability, suggested editor tab width of 8.

(something to that effect)

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 20, 2017

CL https://golang.org/cl/38374 mentions this issue.

gopherbot pushed a commit that referenced this issue Mar 20, 2017
Fixes #19618.

Change-Id: I0ac450ff717ec1f16eb12758c6bf5e98b5de20e8
Reviewed-on: https://go-review.googlesource.com/38374
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
gopherbot pushed a commit that referenced this issue Mar 20, 2017
Since "columns of alignment" are terminated whenever indentation
changes from one line to the next, alignment with spaces will work
independent of the actually chosen tab width. Don't mention tab width
anymore.

Follow-up on https://golang.org/cl/38374/.

For #19618.

Change-Id: I58e47dfde57834f56a98d9119670757a12fb9c41
Reviewed-on: https://go-review.googlesource.com/38379
Reviewed-by: Rob Pike <r@golang.org>
@golang golang locked and limited conversation to collaborators Mar 20, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.