Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
cmd/gofmt: does it have to specify tab width = 8 ? #19618
@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.
@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.
We could write something like:
(Or more or less verbose, at your choosing.)
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@example.com>