
Researchrsc: Gofmt - bandris
http://research.swtch.com/2009/12/gofmt.html
======
JulianMorrison
I love gofmt. I love specifically that in any silly bikeshed-painting argument
about code styles, the answer will be "gofmt is definitive, and this
conversation is over". If you think it makes mistakes, file a bug. If you
don't _like_ it, soldier on. Familiarity will dull the pain.

Oh and, that -r pattern-matching search-and-replace is _nice_.

------
bmm6o
Using a formatter to easily manage breaking language changes is really clever.
I was just reading Pike's interview in Coders at Work where he talked about
how all the language changes in the early days of C++ drove him off. This
should help Google build up a community while still allowing flexibility.

~~~
wglb
Perhaps you mean Ken Thompson?

------
marketer
One problem with this is that it enforces certain styles upon the programmer.
For instance, this function won't compile in go:

    
    
        func main() 
        {
            println("hello world")
        }
    

Instead, if you run gofmt -w on the above code, you get this:

    
    
        func main()     { println("hello world!") }
    

This compiles fine, but it looks ugly.

~~~
omouse
Maybe we can treat Go like assembly language then. Made for a computer to run,
not for a person to read. So we'll need a higher level language and less ugly
language than Go to write Go.

~~~
lsb
Yes, but that's hardly an auspicious beginning to a language.

------
DannoHung
I don't get it. It's a parser that does the output in a particular pretty
printed format? If you knew that you wanted to do that from the start,
wouldn't you write your compiler parser to be a separate piece of code?

Also, banner indenting style is superior!

~~~
gnosis
I also wonder what all the hoopla is about. So Go now has a prettyprinter. Big
f'ing deal. Welcome to the 1980's.

------
aaronblohowiak
Why the legacy "fmt" instead of "format" ? Go is a new language, why be held
back by the old name conventions?

~~~
tspiteri
Because it's shorter.

~~~
ThinkWriteMute
We're not on 80 character terminals anymore. Harddrives are larger than 1.4mb.
People need to _read_ this stuff.

"It's shorter" isn't a reason, it's a legacy.

~~~
tspiteri
When using the command line, shorter commands are easier to type. I know, two
key strokes are not going to take a lot of time, but when you do it
repeatedly, it does feel a bit more comfortable. It has nothing to do with 80
character limits. And in what way do people need to read "gofmt"? They need to
type it, not read it.

~~~
ThinkWriteMute
I guess I forgot that newbies never read code to learn from it? Or when
someone is updating or maintaining old code? Crazy talk!

Look there's no excuse here. goformat isn't that much larger than gofmt,
easier to understand on initial read, and doesn't hurt a damn thing.

If Computers have no problem reading Brainfuck then they should have no
problem reading a Programming Language that reads easily to humans. You know,
those things that actually write and develop in these languages? Ruby made a
stand in this and it turned out very very well.

~~~
tspiteri
gofmt is not a function name, it does not appear in code, it is a command line
tool. In many cases you type something like "gofmt -w filename.go", press
Enter, and then it's gone, never to be read.

In the language itself, fmt (something completely different from gofmt) is
used as a package identifier. In the Go style, package identifiers are typed
repeatedly, the identifiers inside a package are not imported into the global
namespace. So if code contains many calls to the Printf function, there will
be many instances of fmt.Printf. In this case, fmt instead of format is a good
decision too. It's a package name (not a function name) and it is typed
repeatedly, so the shorter it is, the less visual noise.

~~~
aaronblohowiak
I believe in determining brevity by number of tokens, not the length of the
tokens themselves. application names are just as important as function names,
especially when you are automating your workflows.

fmt.Printf is exactly the kind of crap that I hate.
format.PrintFormattedString() is readable. If you are calling it all the time,
then i'd suggest you have an output() function local to your class that
forwards the call on. This is good practice anyway because you should minimize
the tight coupling of your object with a foreign object.

If you watch the Go presentations, the examples using fmt are pronounced
"fumt". fumt neither expresses the domain meaning or the implementation, and
is perpetuating a bad habit.

~~~
jongraehl
Great - you have a preference and gave some principles that define your
aesthetic. I find your alternative to fmt.printf to be horrifying, but then, I
hate Objective C and plenty of people love it.

Fortunately, you can have it your way by using gofmt to show you
format.PrintFormattedString() when you edit, but give fmt.printf to the
compiler.

As for the command name, there's always "ln -s ~/bin/gofmt ~/bin/goformat" or
"alias goformat gofmt".

