7 ms·

The Go team has made the decision that the language supports tabs for indentation, and it’s enforced by `go fmt`.

andrewprock 12y ago
While this is clearly the wrong decision, one has to applaud the Go team for building `go fmt` and thus putting and end to unproductive discussions about formatting. (Although it would have been nice if `go fmt` didn't change code semantics.)
- couchand 12y ago
  I'm relatively new to Go, and like you I wholeheartedly agree with the idea of solving formatting once and being done with it (and as an aside, I agree that tabs are the wrong decision). It was my impression that gofmt was essentially a pretty printer. Can you point to examples where it changes semantics?
  - andrewprock 12y ago
    go fmt will reorder your imports, which means that if there is an import ordering dependency, it will either be exposed (or hidden) by go fmt.
    - ominous_prime 12y ago
      you should never have an import order dependency, since initialization order is unspecified.
      - andrewprock 12y ago
        Shoulda woulda coulda: https://bugs.launchpad.net/gocheck/+bug/1178806 https://bugs.launchpad.net/gocheck/+bug/1178806
        ominous_prime 12y ago
        I say that's great! It helped uncover an otherwise unnoticed bug.
    - couchand 12y ago
      I'm just going to say whoever is downvoting this is a jerk. This comment is actually correct. Whether or not it reflects the way you believe things should happen, this is an accurate description of how things do happen (I assume, based on the other comments, I don't actually know myself).
      - ominous_prime 12y ago
        Yes and no. `gofmt` is a tool to make your code follow certain style guidelines, and the ordering of imports is part of those guidelines. You are always free to ignore the guidelines, but then don't complain about the tool which is created to enforce them. It is also incorrect to rely on the order of import initialization at all, because it's undefined, implementation specific and may change.
        couchand 12y ago
        So it sounds like... yes and yes. Guidelines are guidelines. If they are more than guidelines they must be enforced at the language level. 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.
  - skj 12y ago
    It does not change semantics. If it does in some case, that's a bug and please report it. 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.
    - ominous_prime 12y ago
      no, the order is unspecified, so it shouldn't be relied upon. The only order enforced is that imported packages are initialized before the package itself.
      - MatthewJBrown 12y ago
        In fact, you should be glad that "go fmt" exposed the fact you were relying on something that you should not have. Better to find a bug sooner rather than later, and relying on implementation details of your particular language implementation is a bug.
        couchand 12y ago
        It seems to me like it would be very much in line with the Go philosophy to automatically uncover this in some way other than just an impossible-to-debug pre-compile sort, like disallowing it on a language level. Perhaps that's a Hard Problem, though, so not a reasonable request.
        skj 12y ago
        Well, they could do what they did with map iteration: make it happen arbitrarily different each program execution.
        couchand 12y ago
        Breaking it randomly and requiring debugging is not the same as telling you you're doing something wrong and where.
- dilap 12y ago
  Wait, why is it clearly the wrong decision? I think using tabs for indentation is great. 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?
  - andrewprock 12y ago
    It not a particularly interesting discussion to have. The short of it is, if you only ever use one tool (or family of tools) to look at code (say an IDE), then tabs are not unreasonable. Once you start using multiple families of tools on multiple machines, now you have to maintain T*M tab configurations, which is awful. 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.
    - dilap 12y ago
      I think this stuff is actually pretty interesting, it's programmer tools UX! I use emacs and various command line tools. Tabs don't give me problems. FWIW.
  - ansible 12y ago
    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.
- codygman 12y ago
  That's only if the developers use go fmt though. The only place I've worked at that used Go didn't use go fmt.
  - dilap 12y ago
    That's craziness. Why wouldn't you?
    - codygman 12y ago
      "Sometimes people work faster with code formatted like they are used to" - Code Creator "Well, if we all standardize on the same style we can get used to working faster with the same format giving everyone a net win" - Me "Well we'll have to do it after... later... deadlines... shipping" - Code Creator
- TOMDM 12y ago
  I feel it's worth pointing out the irony in "While this is clearly the wrong decision" and "thus putting and end to unproductive discussions about formatting" considering this is part of a discussion about Go's formatting.

While this is clearly the wrong decision, one has to applaud the Go team for building `go fmt` and thus putting and end to unproductive discussions about formatting. (Although it would have been nice if `go fmt` didn't change code semantics.)

couchand 12y ago
I'm relatively new to Go, and like you I wholeheartedly agree with the idea of solving formatting once and being done with it (and as an aside, I agree that tabs are the wrong decision). It was my impression that gofmt was essentially a pretty printer. Can you point to examples where it changes semantics?
- andrewprock 12y ago
  go fmt will reorder your imports, which means that if there is an import ordering dependency, it will either be exposed (or hidden) by go fmt.
  - ominous_prime 12y ago
    you should never have an import order dependency, since initialization order is unspecified.
    - andrewprock 12y ago
      Shoulda woulda coulda: https://bugs.launchpad.net/gocheck/+bug/1178806 https://bugs.launchpad.net/gocheck/+bug/1178806
      - ominous_prime 12y ago
        I say that's great! It helped uncover an otherwise unnoticed bug.
  - couchand 12y ago
    I'm just going to say whoever is downvoting this is a jerk. This comment is actually correct. Whether or not it reflects the way you believe things should happen, this is an accurate description of how things do happen (I assume, based on the other comments, I don't actually know myself).
    - ominous_prime 12y ago
      Yes and no. `gofmt` is a tool to make your code follow certain style guidelines, and the ordering of imports is part of those guidelines. You are always free to ignore the guidelines, but then don't complain about the tool which is created to enforce them. It is also incorrect to rely on the order of import initialization at all, because it's undefined, implementation specific and may change.
      - couchand 12y ago
        So it sounds like... yes and yes. Guidelines are guidelines. If they are more than guidelines they must be enforced at the language level. 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.
- skj 12y ago
  It does not change semantics. If it does in some case, that's a bug and please report it. 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.
  - ominous_prime 12y ago
    no, the order is unspecified, so it shouldn't be relied upon. The only order enforced is that imported packages are initialized before the package itself.
    - MatthewJBrown 12y ago
      In fact, you should be glad that "go fmt" exposed the fact you were relying on something that you should not have. Better to find a bug sooner rather than later, and relying on implementation details of your particular language implementation is a bug.
      - couchand 12y ago
        It seems to me like it would be very much in line with the Go philosophy to automatically uncover this in some way other than just an impossible-to-debug pre-compile sort, like disallowing it on a language level. Perhaps that's a Hard Problem, though, so not a reasonable request.
        skj 12y ago
        Well, they could do what they did with map iteration: make it happen arbitrarily different each program execution.
        couchand 12y ago
        Breaking it randomly and requiring debugging is not the same as telling you you're doing something wrong and where.
dilap 12y ago
Wait, why is it clearly the wrong decision? I think using tabs for indentation is great. 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?
- andrewprock 12y ago
  It not a particularly interesting discussion to have. The short of it is, if you only ever use one tool (or family of tools) to look at code (say an IDE), then tabs are not unreasonable. Once you start using multiple families of tools on multiple machines, now you have to maintain T*M tab configurations, which is awful. 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.
  - dilap 12y ago
    I think this stuff is actually pretty interesting, it's programmer tools UX! I use emacs and various command line tools. Tabs don't give me problems. FWIW.
- ansible 12y ago
  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.
codygman 12y ago
That's only if the developers use go fmt though. The only place I've worked at that used Go didn't use go fmt.
- dilap 12y ago
  That's craziness. Why wouldn't you?
  - codygman 12y ago
    "Sometimes people work faster with code formatted like they are used to" - Code Creator "Well, if we all standardize on the same style we can get used to working faster with the same format giving everyone a net win" - Me "Well we'll have to do it after... later... deadlines... shipping" - Code Creator
TOMDM 12y ago
I feel it's worth pointing out the irony in "While this is clearly the wrong decision" and "thus putting and end to unproductive discussions about formatting" considering this is part of a discussion about Go's formatting.