OT but I think GitHub should show tabs as 4 columns. I find Go code is hard to read with all this whitespace.
https://github.com/facebookgo/httpcontrol/blob/e815eb2/httpc... (tab size 2)
https://github.com/facebookgo/httpcontrol/blob/e815eb2/httpc... (tab size 4)
https://github.com/facebookgo/httpcontrol/blob/e815eb2/httpc... (tab size 12, seems to be the maximum)
Unfortunately, there seems to be no such entry in the account settings. I'd love to set this value once and for all, or maybe once per file suffix (2 spaces for stuff.xml, 4 spaces for stuff.go).
In fact, this is the only remaining issue I have left at https://shurcool-legacy.github.io/bettertogether/.
But this isn't just a reaction rooted in practicality. To me, this looks and feels absurd. It kind of hurts to read. Again, this is just my personal take.
I prefer scope indentation of any kind to render as 4 spaces, but I'm okay with 2 as well.
Yes, it was just a personal opinion.
It was only used when you invoked the other option to use spaces instead of tabs. Both options are now removed. gofmt doesn't care how wide your tabstops are.
Groups of spaces and tabs are semantically different. Tabs mean indentation. Spaces mean spaces.
Sorry but this is false. The only thing a tab means, is tab.
Please provide your reasoning for the down voting. Thank you.
"A key on a computer keyboard that, when pressed, inserts a special ASCII character used for formatting text, as in indenting a line or block of text."
Actually going back it means tabulation which was an early form of alignment of tables on typewriters. The tab key advanced the carriage to the next tabulation point. It was repurposed as a way of indenting code later and it has become an additional definition of that fact.
(I'm old enough to have owned a typewriter, a nice Selectric one as well ;-)
Anyways, that's besides the point, and I think you missed the meaning behind my comment.
The reason why a tab space cannot semantically mean indentation in our world, is because nobody can agree on what that indentation should be. Since you are old enough to have owned a typewriter, maybe you are old enough to remember that by legacy, a tab was equivalent to exactly 8 spaces, and much of our software that runs the internet makes that assumption. Now however, people are saying "use tab to mean indent and everyone can have their way" To quote mikko, "There is no style guide or coding conventions saying that the tab character should be the indent. This assumption is easy to make because it allows you to stick your head into the sand, ignore the surrounding world and by singing “let the users pick their own tab width” mantra."
Again, this wasn't to start a tab vs spaces war for go, and why go chose tabs. It's fine to make a choice, but it was your second statement that provoked my comment.
It means 1 indent, not 8 spaces, 3 bananas or one tree. It is a unit. How the user displays that is up to them.
I used to hate tabs and want 2 spaces only, until I started working with other developers. Then suddenly tabs made sense, especially when you've got IDEs coercing every edited file to a person's indentation standard. Standardize on the tab and the pain goes away.
Sure there is: http://en.wikipedia.org/wiki/IEEE_754-1985#Positive_and_nega...
I agree gofmt is amazing, and for any language I'd happily trade whatever my personal style is for consistency and and gofmt-like tool.
Can gofmt really change semantics? I would assume that's a bug?
It is definitely not supposed to change semantics. If you ever see an instance of that, then it is a big fat bug and should be reported to the developers ASAP.
I doubt you'll see such a bug though. The language is designed to be easy for a computer to parse.
The "standard" alternative (e.g. the google c++ style guide) advises 2-space indentation with 80 column lines. That specific format works well with almost every tool in existence. Tabs, not so much.
You can google "jwz tabs" to get a more in depth discussion. It's not a "big" deal, and as noted, in many ways it's better to standardize on the "wrong" decision than to constantly hash it out over formatting sugar.
I use emacs and various command line tools. Tabs don't give me problems. FWIW.
It was my impression that gofmt was essentially a pretty printer. Can you point to examples where it changes semantics?
Edit: I see, import order can affect the order that the init()s in different packages are invoked, presumably. I stand corrected.
Edit 2: But that should not matter since the language doesn't specify any dependence on that.
The same exact argument applies. The code was broken to begin with, the implementation behavior did not break anything.
And, just like with map iteration ordering, it's very difficult/impossible for the compiler to say "hey don't depend on this!".
The only way that I can think of to get this concept (that import order in code and init() order in runtime are unrelated) is to have things break.
I suppose if the runtime randomizes things, at least you would never experience it consistently working in the first place, so maybe the issue wouldn't ever come up.
Regarding static initializers, I use them for precompiling regexps and templates, but not much more than that.
It is also incorrect to rely on the order of import initialization at all, because it's undefined, implementation specific and may change.
Undefined behavior is another thing. Surely, it's poor form to rely on undefined behavior. However, that doesn't mean it isn't possible for such a situation to arise. An accurate description of how that can happen doesn't deserve a downvote.
On the contrary, it's quite valuable for a newbie (like myself) to learn the facts, not just the dogma. Downvoting an accurate description of the behavior of the tool because you think the situation shouldn't arise in the first place is simply a misplaced use of a downvote.