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.
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.
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?
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".
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."
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?
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'?
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.
Oh and, that -r pattern-matching search-and-replace is nice.