-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/gofmt: does it have to specify tab width = 8 ? #19618
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
Comments
Perhaps this has something to do with padding of comments, assignments and key-value pairs, since those are done with spaces. |
cc @griesemer |
@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. |
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. |
@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:
We could write something like:
(Or more or less verbose, at your choosing.) |
I think @bradfitz's suggestion makes it much clearer without being verbose. I assume we don't want to get into historical details there. |
CL https://golang.org/cl/38374 mentions this issue. |
Fixes #19618. Change-Id: I0ac450ff717ec1f16eb12758c6bf5e98b5de20e8 Reviewed-on: https://go-review.googlesource.com/38374 Reviewed-by: Brad Fitzpatrick <[email protected]>
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 <[email protected]>
https://tip.golang.org/cmd/gofmt/
Does it need to specify tab width = 8? If not, could you please remove it?
The text was updated successfully, but these errors were encountered: