Refactoring with go fmt

http://spf13.com/post/go-fmt

by spf13 • 13 years ago

86 40 13 years ago

spf13.com

motter• 13 years ago

`go vet` (checks correctness) and golint (https://github.com/golang/lint) are also extremely useful.

As a whole the toolchain makes working with Go code very convenient.

JulianMorrison• 13 years ago

Also, go run -race

drtse4• 13 years ago

Was going to post this, agreed, those can really be useful while doing real refactoring.

chewxy• 13 years ago

You can even use gofmt to export variables that you want exported throughout the project. I wrote about it on this coderwall: https://coderwall.com/p/ds3iuw

edit: aha, the article did mention "gofmt -r"

sillysaurus22• 13 years ago

Go fmt isn’t without it’s detractors. People complain that go fmt isn’t customizable and that it puts braces where they don’t want them. Fools.

How would you feel if I left a comment calling you a fool for writing such a remark? Now realize you're giving that same feeling to every reader you're trying to convince.

It's far more effective to point out why someone is mistaken and leave it at that, as 'pg has demonstrated over the years.

mherdeg• 13 years ago

If you find this kind of tone off-putting, whatever you do, don't read the scsh acknowledgments ( http://www.scsh.net/docu/html/man.html )!

sillysaurus22• 13 years ago

That wasn't meant to be persuasive, though. Here's a more analogous example from that same author: http://www.paulgraham.com/thist.html

RBerenguel• 13 years ago

I don't think this should be taken hardly. A lot of people (from what I've seen) complain about go fmt doing things they don't like (bracing structure, indentation, etc.) For me it was no big deal since my bracing "standard" (what I did 90% of the time out of luck) is almost the same as go. And most people complaining just don't try to (ehem) go with it: once you are used to seeing your code neatly formatted automagically, always exactly the same, you start to see how neat it is. Also, being able to read other people's go code without hiccups is awesome.

spf133• 13 years ago

Wasn't intended to offend. I'll reword that sentence. I do go on to explain why it's a mistake. It's really just that one word that seems to offend.

melling• 13 years ago

I'm sure Go puts the curly's in a few incorrect places. :-)

I would gladly trade that for never having to worry about it again. ask_two peopleForTheir_opinion any YOU'LL get 3_answers. Just pick one standard and get over it.

Someday there will be a billion lines of Go and it will all be formatted to the same standard.

rtpg• 13 years ago

I read it as tongue in cheek.

Think this is the first time I've read about someone being offended for being called a fool, maybe this is just a touchy subject for some people(not trying to be snarky)

CmonDev• 13 years ago

'golang' would me more appropriate in the subj. I thought it was something generic

jimktrains2• 13 years ago

The command is go and it's argument is fmt.

cdoxsey• 13 years ago

The Go Sublime plugin will go fmt your code on save:

https://github.com/DisposaBoy/GoSublime

It's nice not having to think about proper spacing anymore and just focusing on writing the code itself.

spf133• 13 years ago

The Go project provides similar functionality for most common editors (Emacs, Vim). The spf13-vim distribution supports this for Vim.

nahname• 13 years ago

This was one of my favorite parts about jetbrains products. Auto cleanup right while you are coding. Push devs, kicking and screaming sometimes, into the pit of success.

simias2• 13 years ago

As a C coder I really wish it had a standard syntax and a similar tool to deal with that. Dealing with proper style is a constant headache among a team. And I always feel like a "coding style nazi" when I bother other people to tell them "you should put spaces here", "your braces are not in the correct position", "you shouldn't use TABs there" etc...

So in the end I stop doing it (or I let small mistakes go by) and soon enough the whole codebase is heterogeneous and looks like crap everywhere.

I don't really care about Go and never used it but this is a very good move on their part IMO. No bickering allowed, it's standard. No arguing, just run "go fmt" and you're set. Brilliant.

pjmlp5• 13 years ago

Easy, integrate indent in the source control checkin hooks.

No more arguing.

simias2• 13 years ago

Yeah, obviously but it's not "Standard". If I do that next thing will be "but I think we should change indent option X because it's better that way".

In the long run it would probably be a good thing but I'm not sure I'm ready to go through the massive flamewar that would be at first.

In the end I wouldn't mind this being handled at "language" level. Maybe even a flag in GCC that would warn/error on a coding style error. It would save everybody time, resources and probably a few friendships along the way.

RogerL• 13 years ago

This is conceptually nice. But consider. You want to fork a third party library. On check in you reformat the entire code base? Or, if you don't do it on initial commit, and then somebody needs to modify one line?

Recognize that "third party" might not mean some code base from NVIDIA or whatever, but just some code from 5 years ago in your own company.

And sure, we could enforce the same tool chain on the entire company, but then you have broken diff on probably every line of code in every repository. And the embedded guys are up in arms because it makes bad decisions for their hardware, which is limited to 40 column displays. And so on.

Go got it right. They had green field development, and made the decision on formatting then. I'm not crazy about a few of the specific choices they made, but who cares, really?

Personally, I would like a tool that inspected the code, recognized the style, and then enforced that style. Braces on the same line, well, that is how all new lines will be formatted. And so on. I live and die by source code diffs, and don't want formatting wars to break that. I also spend every day in multiple code bases not written by the company, so I already deal with different formatting styles. It ain't hard to deal with, excepting that terrible Microsoft C style of spacing ('foo( x ,y )' vs 'foo (x, y)'. My eyes can't parse that quickly because it breaks all the normal rules of punctuation that we use in English and every other computer language. (I don't know that MS invented it, it is just pervasive in their code, and it is where I usually encounter it)

All of that is not to say I completely disagree with your idea, it is attractive in a number of ways, I am just pointing out some tradeoffs (and putting the lie to your "no more arguing" ;))

DSMan195276• 13 years ago

I agree and disagree -- I don't like the idea of C having a standard syntax, but I would like having a simple program people run their code through the points out any format mistakes. I think in general you could easily handle this using a simple perl script or similar, just require people to run their code through it before submitting. Then it's simple, and you can just point to the program to use and policy for submitting code if someone breaks syntax.

sbi• 13 years ago

There are tools for standardizing C formatting. Another poster mentioned indent. Clang-format [1] is very good, works with C++ as well as C, and has great editor integration. You can choose among predefined style (e.g. Google, Mozilla, LLVM style guides) or create your own and then and enforce it within a source tree very easily.

[1] http://clang.llvm.org/docs/ClangFormat.html

bradleyjg2• 13 years ago

In addition to being instructions for the compiler, source is also a text designed to be read. Specifying and universally enforcing too rigid a rule-set is a bad idea. Good authors sometimes need to break rules in order to make a text better.

Imagine if novels were put through Microsoft Word spelling and grammar check just prior to publication and automatically had all the changes accepted.

The python style guide gets this right, quoting Emerson's famous maxim that "A foolish consistency is the hobgoblin of little minds."

thezilch• 13 years ago

Can you say where `go fmt` gets it wrong -- give an example. Or where a consistent formatting has gone wrong, in any language? I prefer 2 space python, but I don't have a better reason than my team, as a majority, prefer condenser line lengths, but it can be a problem having to gear up to work with a lib that follows PEP8 to the t.

pjmlp5• 13 years ago

While go fmt is great tool, it is no different than integrating indent or similar tool in the source control system.

4ad• 13 years ago

Indent(1) is a textual tool while gofmt does full syntactic analysis. Among other things, indent(1) can't refactor code.

pjmlp5• 13 years ago

I just gave indent as a possible example, there are other tools.

chimeracoder3• 13 years ago

People complain that go fmt isn’t customizable and that it puts braces where they don’t want them.

I assume this is referring to putting opening braces on the next line.

IIRC, this has nothing to do with the `go fmt` tool - unlike in C, this is actually a syntax error in Go: http://play.golang.org/p/bn30UNkr1z

One of the reasons for this decision is because it helps enforce a truly context-free grammar for the language.

Ironically, the fact that Go has a nearly context-free grammar is what allows tools like `go fmt` and the obsolete `go fix` to make modifications to the code deterministically, with guarantees that it will not change the behavior of the code.

lucian19003• 13 years ago

That is by far not the only way to do have a context-free grammar. Python for example also has a context-free grammar without semicolon insertion.

chimeracoder3• 13 years ago

A) Python is not context-free; this is a common misconception: http://trevorjim.com/python-is-not-context-free/

B) No one feature of a grammar provides context-freedom. It's not meaningful to compare Go's grammar to another grammar; it's meaningful to compare Go's grammar as-is to the way it would be if it allowed both forms.

In this case, I believe the same-line braces rule is not strictly necessary by itself (they could have gotten a context-free grammar other ways), but this was (part of) one approach.

vph• 13 years ago

This is nice, but I don't think it is refactoring.

spf133• 13 years ago

The second half of the article is all about refactoring. Very similar to the refactor functionality provided by Eclipse & IntelliJ.

bct• 13 years ago

Maybe there are better examples, but removing parentheses and renaming a field are so trivial that I would not refer to them as refactoring.

Refactoring with go fmt

Related Stories