4 ms·

> Using rustfmt ensures that all of your Rust code conforms to the same style, like clang format does for C++ and Prettier does for JavaScript. Oh, and also th

by dilap 8y ago

> Using rustfmt ensures that all of your Rust code conforms to the same style, like clang format does for C++ and Prettier does for JavaScript. Oh, and also this obscure little program gofmt ;-)

steveklabnik 8y ago
gofmt was certainly a huge inspiration here, and many of us are jealous that go had it so early in their evolution. Not sure why it wasn't included!
- vanderZwan 8y ago
  Seriously though, the Go core team has been saying from the start that even they were surprised how big of a positive impact gofmt had. It reduces bikeshedding and makes it easier for people to read each other's code because you learn to read the same basic structure fluently and quickly. It's a basic IxD lesson about software tooling that I think more languages should pick up on. Personally, I think I miss gofmt-on-save more than any other feature when I write other languages (gofmt is a lot more robust than autoformatters in most other languages). Being able to type carelessly and quickly and know the output will be corrected as soon as I hit CTRL+S lets me focus on putting my thoughts on the screen. And it even works as a soft-compiler: if the autoformatter breaks it means I have a bug somewhere.
  - dan_quixote 8y ago
    > It reduces bikeshedding My team works in equal parts go, ruby and javascript. Code review for go code is SO much easier. And it's mostly thanks to gofmt. It still amazes me how fervently some will argue about a single line of white-space or an optional semi-colon...
- renox 8y ago
  Golang, perhaps it is good I don't know but clang format sucks: it improves slightly normal code but the price is too high as sometimes it totally butcher code making it unreadable. Macro+lambda expression makes code formatters generates ugly things (I don't know what clion use to parse code but it also goes nut thinking wrongly that some code is unreachable..)
saghm 8y ago
To be fair, one of the most useful features of rustfmt/clang-format in my opinion is reformatting things that go beyond a maximum line length, which also seems like one of the harder parts to implement in a way that's useful. At leas the last time I used it, gofmt punted on this issue.
- dilap 8y ago
  Personally, I think gofmt made the right call -- let the editor soft-wrap long lines. This is much nicer because you can then dynamically pick whatever window width you want. Hard wrapping defeats this. (But of course there are downsides, because if you're in a context where the editor/viewer isn't soft wrapping, it's worse. Still, on balance, I think not manually wrapping lines is the way to go.)
  - deleted 8y ago
    [deleted]
  - kibwen 8y ago
    A lot of it depends on the properties of the language itself. Traditional C-style imperative code involves many short statements each doing one small thing, one expression per statement, one statement per line; this makes it simple to punt on wrapping long lines (which is 90% of the difficulty of writing an automatic code formatter). Go inherits this "tall-and-narrow" idiomatic style. But other languages, especially ones that try to encourage fluent APIs, will often have several expressions within each logical statement, leading to fewer lines of code overall but more action on each line. In these languages it tends to be idiomatic to break the statement across multiple lines (usually at method calls), in which case an automatic code formatter's job is to do this operation manually.
    - dilap 8y ago
      Seems like you're talking about splitting statements over multiple lines because it aids comprehension and makes sense semantically. Code-formatters are concerned with splitting lines that exceed some arbitrary line limit, no? The former it seems like it makes sense for me to do as the human authoring the code for readability (it seems a very similar decision to, "do I assign this value to a variable or include it inline"), the latter makes sense to do dynamically, given the line-length-limit of the moment. That said, no experience with these languages, so maybe I'm way off base. I'd be curious to see code samples, if you really feel like digging deep. :-)
littlestymaar 8y ago
Well, Go is still an obscure programming language compared to C++ or JavaScript :)
pjmlp 8y ago
Which got its inspiration from the obscure little UNIX utility called indent, being used during the 90's on CVS pre-commit hooks.
- vanderZwan 8y ago
  Eh, IIRC Go was somewhat designed with "easy to autoformat"-semantics in mind. Or at least it just happened to overlap really well with the goal of being fast to compile.
  - pjmlp 8y ago
    Languages like Delphi were easy to autoformat on save during the 90's, while compiling relatively fast and being much more feature rich than Go.
    - vanderZwan 8y ago
      Sure, but you were talking about the Unix tool indent, which as far as I can tell based on its Wiki page was written to format C. https://en.wikipedia.org/wiki/Indent_%28Unix%29 https://en.wikipedia.org/wiki/Indent_%28Unix%29
      - pjmlp 8y ago
        I was, because I was making the point that there isn't anything special about gofmt other that not being aware of previous tools.
        dilap 8y ago
        Go's innovation was social: it was saying: "Here's the code formatter, use it, always. There is one style, use it, always."
        vanderZwan 8y ago
        Exactly. Saying gofmt didn't change anything is a bit like saying the invention of the camera was nothing new because the technologies to create one existed for a century before they were combined.

by dilap 8y ago

> Using rustfmt ensures that all of your Rust code conforms to the same style, like clang format does for C++ and Prettier does for JavaScript. Oh, and also this obscure little program gofmt ;-)

steveklabnik 8y ago

gofmt was certainly a huge inspiration here, and many of us are jealous that go had it so early in their evolution. Not sure why it wasn't included!

vanderZwan 8y ago
Seriously though, the Go core team has been saying from the start that even they were surprised how big of a positive impact gofmt had. It reduces bikeshedding and makes it easier for people to read each other's code because you learn to read the same basic structure fluently and quickly. It's a basic IxD lesson about software tooling that I think more languages should pick up on. Personally, I think I miss gofmt-on-save more than any other feature when I write other languages (gofmt is a lot more robust than autoformatters in most other languages). Being able to type carelessly and quickly and know the output will be corrected as soon as I hit CTRL+S lets me focus on putting my thoughts on the screen. And it even works as a soft-compiler: if the autoformatter breaks it means I have a bug somewhere.
- dan_quixote 8y ago
  > It reduces bikeshedding My team works in equal parts go, ruby and javascript. Code review for go code is SO much easier. And it's mostly thanks to gofmt. It still amazes me how fervently some will argue about a single line of white-space or an optional semi-colon...
renox 8y ago
Golang, perhaps it is good I don't know but clang format sucks: it improves slightly normal code but the price is too high as sometimes it totally butcher code making it unreadable. Macro+lambda expression makes code formatters generates ugly things (I don't know what clion use to parse code but it also goes nut thinking wrongly that some code is unreachable..)

saghm 8y ago

To be fair, one of the most useful features of rustfmt/clang-format in my opinion is reformatting things that go beyond a maximum line length, which also seems like one of the harder parts to implement in a way that's useful. At leas the last time I used it, gofmt punted on this issue.

dilap 8y ago
Personally, I think gofmt made the right call -- let the editor soft-wrap long lines. This is much nicer because you can then dynamically pick whatever window width you want. Hard wrapping defeats this. (But of course there are downsides, because if you're in a context where the editor/viewer isn't soft wrapping, it's worse. Still, on balance, I think not manually wrapping lines is the way to go.)
- deleted 8y ago
  [deleted]
- kibwen 8y ago
  A lot of it depends on the properties of the language itself. Traditional C-style imperative code involves many short statements each doing one small thing, one expression per statement, one statement per line; this makes it simple to punt on wrapping long lines (which is 90% of the difficulty of writing an automatic code formatter). Go inherits this "tall-and-narrow" idiomatic style. But other languages, especially ones that try to encourage fluent APIs, will often have several expressions within each logical statement, leading to fewer lines of code overall but more action on each line. In these languages it tends to be idiomatic to break the statement across multiple lines (usually at method calls), in which case an automatic code formatter's job is to do this operation manually.
  - dilap 8y ago
    Seems like you're talking about splitting statements over multiple lines because it aids comprehension and makes sense semantically. Code-formatters are concerned with splitting lines that exceed some arbitrary line limit, no? The former it seems like it makes sense for me to do as the human authoring the code for readability (it seems a very similar decision to, "do I assign this value to a variable or include it inline"), the latter makes sense to do dynamically, given the line-length-limit of the moment. That said, no experience with these languages, so maybe I'm way off base. I'd be curious to see code samples, if you really feel like digging deep. :-)

littlestymaar 8y ago

Well, Go is still an obscure programming language compared to C++ or JavaScript :)

pjmlp 8y ago

Which got its inspiration from the obscure little UNIX utility called indent, being used during the 90's on CVS pre-commit hooks.

vanderZwan 8y ago
Eh, IIRC Go was somewhat designed with "easy to autoformat"-semantics in mind. Or at least it just happened to overlap really well with the goal of being fast to compile.
- pjmlp 8y ago
  Languages like Delphi were easy to autoformat on save during the 90's, while compiling relatively fast and being much more feature rich than Go.
  - vanderZwan 8y ago
    Sure, but you were talking about the Unix tool indent, which as far as I can tell based on its Wiki page was written to format C. https://en.wikipedia.org/wiki/Indent_%28Unix%29 https://en.wikipedia.org/wiki/Indent_%28Unix%29
    - pjmlp 8y ago
      I was, because I was making the point that there isn't anything special about gofmt other that not being aware of previous tools.
      - dilap 8y ago
        Go's innovation was social: it was saying: "Here's the code formatter, use it, always. There is one style, use it, always."
        vanderZwan 8y ago
        Exactly. Saying gofmt didn't change anything is a bit like saying the invention of the camera was nothing new because the technologies to create one existed for a century before they were combined.