Researchrsc: Gofmt | Hacker News Reader

Researchrsc: Gofmt

research.swtch.com

33 pointsbandris34 comments

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.

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.

Perhaps you mean Ken Thompson?

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.

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.

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

Are you sure the first one doesn't compile (provided that you change println to fmt.Println, of course)?

I can compile (with 6g) the hello world example from golang.org with any brace indentation style.

Make sure you're running the latest parser code; do an 'hg sync' on the go tree.

Or you can read the relevant mailing list thread:

http://groups.google.com/group/golang-nuts/browse_thread/thr...

Ha-ha, you're right, thanks for the link! I think this is really bad.

    func main()
    {

is read as:

    func main();
    {

due to the new semicolon-inserting lexer rules. If you use the gofmt style, you won't notice this breaking change.

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!

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

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

Because it's shorter.

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.

It's legacy in the sense that there is a piece of software called "fmt," but I think this is the Go guys basically saying, "Here's our version of that."

I'm talking more about shortening words where they don't need to be shortened.

For instance one of my beefs with Ruby (My main language) is: elsif. Would it really have been so difficult to have "elseif"? No.

Your Ruby example is to help the developer.

Let's say you are skimming your code. Are you going to quickly and easily see the difference between "elseif" and "else if"?

Creating a new word, while superficially unwieldly, keeps you from wasting valuable time debugging one of those "d'oh!" bugs.

And the developer who writes "elseif" instead of "elsif" because "else" is a word and "els" isn't? Sorry that argument works both ways.

What I'm saying is that if "else" and "elseif" were both in the grammar (and "elsif" didn't exist), you could have typed "else if" when you meant to type "elseif" and vice-versa and the mistake could easily be overlooked as your code would be syntactically correct, parsing and running and doing the wrong thing.

Now, in Ruby, if you type "elseif" your code will not run. Problem avoided.

The point of Ruby's "elsif" and Python's "elif" is to have visually disparate representations of the two kinds of code blocks (that have different control flows!) that a developer could easily overlook.

The difference is there to help out you and every other developer that use languages that don't use a visible token to separate code blocks, I promise.

"you could have typed "else if" when you meant to type "elseif" and vice-versa and the mistake could easily be overlooked as your code would be syntactically correct, parsing and running and doing the wrong thing."

can you give an example where this would make a difference?

Yes, it's a legacy style from the old K&R folks themselves.

I appreciate it; it's become an aesthetic, actually.

It's the kind of behavior that needs to get left behind.

goformat is easier to understand than 'gofmt'. 3 characters.

It's the kind of behavior that needs to get left behind.

Why? This smacks of religion to me.

goformat is easier to understand than 'gofmt'.

Only if you can't be arsed to learn the language or tools. If the fact that the tool has a different name than you would like is that troublesome, symlink or alias it.

Would it be better if I had to type out 'secure-file-transport-protocol' in the shell instead of 'sftp'?

Yes, compare the 31 character to 4 character acronym to something that isnt: An acronym or very long at all.

"Why? This smacks of religion to me."

The dogma of explicit names is preferable to the dogma of legacy.

"Only if you can't be arsed to learn the language or tools."

I contend that resolving fmt to format increases the complexity in reading and learning Go. Complexity is only tolerable when it provides benefit. The two proposed benefits are token brevity and legacy. I do not believe that preserving the legacy names of commands and packages is a benefit for a "new systems programming language" that is intended to replace the very legacy it is preserving.

What a fantastic bikeshed* we have here.

* http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality

Also, "fmt" is an old Unix formatting command, which name "gofmt" builds on. There's history there.

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.

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.

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.

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.

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".

Why did you write "we're" instead of "we are"? Is this some kind of legacy stuff?

Reply on news.ycombinator.com