6 ms·

You're right. There are other tools out there. But what I really appreciate about gofmt are a few things: * It's highly opinionated. It's not cluttered with cu

You're right. There are other tools out there. But what I really appreciate about gofmt are a few things: * It's highly opinionated. It's not cluttered with customization options. This means your Go program and my Go program are formatted exactly the same. Period. I don't have to choose between spaces or tabs or get annoyed that you chose spaces when tabs are clearly superior. * By being highly opinionated, Gofmt just takes care of those decisions. You focus 100% on coding -- not on stylistic decisions. * It's practically built in and maintained by the core team. The "other tools" out there are usually open-source. You have to go hunting for them. Gofmt ships right with Go. Then you have to figure out how to run them. With go, it's just a simple `gofmt <file>`. Boom. Done. No NPM dependencies, no Ruby gems to install. Just run it and move on. I don't write Go full-time, but I've started adopting similar tools for my primary languages. My editor at my current job runs a similar tool for Node. I don't have to think about style any more. It's just taken care of for me. And all of my team have reached the same conclusion. Peace of mind and focus on what really matters is invaluable.

spion 11y ago
The reason I don't get it, I think is that I've never cared about stylistic decisions, ever. Why would anyone care, I have no idea. I can configure my editor for either spaces or tabs. I run npm install when starting with the project anyway, and it will also fetch any devDependencies for me (which means a script such as npm run stylecheck can be made available). The project lead decides the rules. Or there can be no style rules, it doesn't matter - most of those are very superficial and have little to no effect on anything.
- kyrra 11y ago
  Almost all Go code you find on the web will be formatted the same. It removed some pain points when looking at someone else's code. It also complete removes the discussion about formatting during code reviews with team members. While you may not be opinionated on the matter, many people will learn a certain formatting style and stick with it. They then bring it to their new company and it can cause some minor conflict. Gofmt helps remove that.
  - spion 11y ago
    Any code reformatting tool helps remove that. Gofmt isn't the only code reformatting tool in existence.
- Jemaclus 11y ago
  You obviously don't work with a team, or you work with a team that also doesn't have opinions about style. That's probably not a great thing. The tab-vs-spaces debate is very real, as well as things like whether hanging commas or trailing spaces are allowed, or whether you put one-if-blocks on one line or if you have to split them up into multiple lines, or whether the opening bracket goes on the same line or the next line, or whether... I could go on. All of these are things people tend to have preferences for, so when you work with multiple people, having a consistent style is a huge benefit to reading other people's code. Imagine a simple CSS example: Some people like to do one line per element, while others like one line per style: ``` a { font-weight: bold; color: blue; text-decoration: none; } ``` vs ``` a { font-weight: bold; color: blue; text-decoration: none; } ``` That's a pretty trivial example, and for many people, both are acceptable. But when you get into large projects with hundreds or thousands of styles, or you have to code review that one change that was made off-screen on a really long line of CSS, one of those styles is going to be more conducive to code reviews and readability. Stylistic concerns are very real, and gofmt largely makes those go away. Like kyrra said, you may not be opinionated on the matter, but other people are, and gofmt, et al, completely remove that concern from the table.
  - Jemaclus 11y ago
    erk, that totally screwed up my code example... sorry. :)
  - spion 11y ago
    Like I said, other code reformatting tools exist, the team lead picks the tool and tool settings, and that should be the end of it.
    - Jemaclus 11y ago
      Yes, this is true, but you're overlooking a few of the things I mentioned earlier. Gofmt is extremely opinionated -- you can't customize it. Most other tools involve customizing to fit your own style conventions. Gofmt doesn't allow that. Gofmt also ships with Go, so it's a built-in language tool, not a third-party tool. That's a huge benefit right out the gate, meaning that everyone's code will look the same. You don't really appreciate how nice this is until it's actually true Finally, gofmt is dead simple to use. `gofmt <file>`. Boom. Done. Compare with, say, PHPCS, which is like: `phpcs --standards=<standards-file-path> --autofix=true --exclude=<exclude path>` and so on. Gofmt is just stupid simple to use. Yes, you're right that other tools exist, but gofmt is the one that really makes it click for developers, and they think "Man, THIS is how code formatting should work." And then we take it over to the other languages, to C or Python or Javascript or PHP, and we introduce tools that are similar to gofmt. That's why gofmt in particular has "changed my life" (hyperbole, sure, but the point remains that I code completely differently now). Without gofmt, it's doubtful I'd ever adopt code formatting tools to the point that I have today.

spion 11y ago

The reason I don't get it, I think is that I've never cared about stylistic decisions, ever. Why would anyone care, I have no idea. I can configure my editor for either spaces or tabs. I run npm install when starting with the project anyway, and it will also fetch any devDependencies for me (which means a script such as npm run stylecheck can be made available). The project lead decides the rules. Or there can be no style rules, it doesn't matter - most of those are very superficial and have little to no effect on anything.

kyrra 11y ago
Almost all Go code you find on the web will be formatted the same. It removed some pain points when looking at someone else's code. It also complete removes the discussion about formatting during code reviews with team members. While you may not be opinionated on the matter, many people will learn a certain formatting style and stick with it. They then bring it to their new company and it can cause some minor conflict. Gofmt helps remove that.
- spion 11y ago
  Any code reformatting tool helps remove that. Gofmt isn't the only code reformatting tool in existence.
Jemaclus 11y ago
You obviously don't work with a team, or you work with a team that also doesn't have opinions about style. That's probably not a great thing. The tab-vs-spaces debate is very real, as well as things like whether hanging commas or trailing spaces are allowed, or whether you put one-if-blocks on one line or if you have to split them up into multiple lines, or whether the opening bracket goes on the same line or the next line, or whether... I could go on. All of these are things people tend to have preferences for, so when you work with multiple people, having a consistent style is a huge benefit to reading other people's code. Imagine a simple CSS example: Some people like to do one line per element, while others like one line per style: ``` a { font-weight: bold; color: blue; text-decoration: none; } ``` vs ``` a { font-weight: bold; color: blue; text-decoration: none; } ``` That's a pretty trivial example, and for many people, both are acceptable. But when you get into large projects with hundreds or thousands of styles, or you have to code review that one change that was made off-screen on a really long line of CSS, one of those styles is going to be more conducive to code reviews and readability. Stylistic concerns are very real, and gofmt largely makes those go away. Like kyrra said, you may not be opinionated on the matter, but other people are, and gofmt, et al, completely remove that concern from the table.
- Jemaclus 11y ago
  erk, that totally screwed up my code example... sorry. :)
- spion 11y ago
  Like I said, other code reformatting tools exist, the team lead picks the tool and tool settings, and that should be the end of it.
  - Jemaclus 11y ago
    Yes, this is true, but you're overlooking a few of the things I mentioned earlier. Gofmt is extremely opinionated -- you can't customize it. Most other tools involve customizing to fit your own style conventions. Gofmt doesn't allow that. Gofmt also ships with Go, so it's a built-in language tool, not a third-party tool. That's a huge benefit right out the gate, meaning that everyone's code will look the same. You don't really appreciate how nice this is until it's actually true Finally, gofmt is dead simple to use. `gofmt <file>`. Boom. Done. Compare with, say, PHPCS, which is like: `phpcs --standards=<standards-file-path> --autofix=true --exclude=<exclude path>` and so on. Gofmt is just stupid simple to use. Yes, you're right that other tools exist, but gofmt is the one that really makes it click for developers, and they think "Man, THIS is how code formatting should work." And then we take it over to the other languages, to C or Python or Javascript or PHP, and we introduce tools that are similar to gofmt. That's why gofmt in particular has "changed my life" (hyperbole, sure, but the point remains that I code completely differently now). Without gofmt, it's doubtful I'd ever adopt code formatting tools to the point that I have today.