gofmt: organize imports like eclipse does

[Jonas Wagner]

Hello,

this is my first request concerning this promising new language ;)

During my tests, I realized that gofmt doesn't seem to care about the
order of imports.

In my projects, I usually keep them in alphabetical order, with a blank
line between the standard library, other libraries and project-specific
imports. This is also what eclipse does if one uses the "organize
imports" command.

In my oppinion, it would be nice if gofmt did organize imports in this
manner. In the contest of go, sorting alphabetically would probably mean
by package (not by the alias). What do others think about that?

To give an example, consider the following (modified from gofmt.go):
before:
import (
"io";
"go/parser";
"bytes";
"flag";
"fmt";
"go/printer";
"go/scanner";
"os";
foo "path";
"strings";
)

after:
import (
"bytes";
"flag";
"fmt";
"io";
"os";
foo "path";
"strings";

"go/parser";
"go/printer";
"go/scanner";
)

Best,
Jonas

[Isaac Wagner]

This would be nice, I think. The whole point of gofmt is to standardize
formatting for all go work, and having nicely organized import's is certainly
a kind of formatting. You should submit this as a feature suggestion in the
issue tracker.

--
- Isaac Wagner

[Jonas Wagner]

> This would be nice, I think. The whole point of gofmt is to standardize
> formatting for all go work, and having nicely organized import's is certainly
> a kind of formatting. You should submit this as a feature suggestion in the
> issue tracker.

Filed as Issue 346: http://code.google.com/p/go/issues/detail?id=346

Cheers,
Jonas

[Russ Cox]

I agree about gofmt sorting the imports.

I am skeptical about mimicking Eclipse. In particular:

> import (
>        "bytes";
>        "flag";
>        "fmt";
>        "io";
>        "os";
>        foo "path";
>        "strings";
>
>        "go/parser";
>        "go/printer";
>        "go/scanner";
> )

This example doesn't really apply, because "go/" is a package
hierarchy, not a separate project. If I import "container/vector"
does that go into its own block? What about "hash/crc32"?

The general idea is good, though. For programs we write inside
Google, we have taken to organizing the imports as two blocks
as above, except the distinction is between standard packages
and google-internal packages (all of which have a distinguishing
google prefix).

I think we still need more time to experiment before codifying
something in gofmt, but I expect that gofmt will eventually do
something along these lines. One possibility would be to split
the import block into chunks separated by blank lines (or
comment-only lines) and then have gofmt sort the individual
chunks. Then it would be up to the programmer to categorize
the imports according to local convention, and gofmt would just
sort the categories.

Russ