Vision

What

We want to create the best Go development experience across all the tools available.

We want to be opinionated, correct and helpful about best practices that are available inside the Go community. We want to take the developer's mind off the tooling and enable them to get into a state of "flow" while coding in Go.

How

To achieve this we need to hold ourselves to a set of principles to deliver the What. These principles are:

• no surprises
• no lies
• be a coach

The principle of no surprise

What this means is that we should behave as similar as possible with the standard toolchain. When we are doing this we should be as transparent to the user as possible.

Also it implies that if we are doing something in a particular way, that is different either in a positive or in a negative way, we need to always have an explanation of why did we do it. As a concrete example if we highlight an invalid index expression (because the index expression is not a constant) we need to tell the user why we think that's the case and why we are looking at that issue in the first place (point them to language spec is a good way to do that). This helps in two ways:

• allows the user, which is usually smarter than us, to understand why we did what we did and correct themselves if that's the case
• or allows the user to more easily file a proper bug report so that we have a shorter time to fix it.

If we are forced to do something that is not strictly matching the toolchain, because of technical / skill limitations for example, we need to take the time to explain what is the correct way, according to the toolchain, why are we doing what we are doing, and when our hacking way is required and why.

The principle of no lies

If we can't do something helpful or correct we shouldn't do it at all. We should only advertise functionality that is working according to our intent and we should always be able to explain our choices according to the first principle.

Be a coach

Once we hit parity with the toolchain we should think of higher level features which are helpful in coaching our users to make the best of the go platform. In order to be able to do this we should always strive to understand the particular use cases of each one of our users and try to either coach them towards a better way or support them if that's something missing from the plugin functionality.

Functionality

There are 2 levels of functionality that needs to be built in the plugin in the spirit of these three principles in order for us to be successful. I classify them in two main classes: tablestakes and the rest.

Tablestakes - things that level the playing field

• External compiler support (trace error back to sources)

• Robust / fast parsing of source files

• Perfect resolving of literals to definitions

• Basic inspections like:

  • Expression should be constant
  • Constant expression evaluation and highlighting of cast / conversions
  • return statement inspection (parameter count mismatch with quick fixes where appropriate)
  • multiple-var expr in single-var context
  • unused var / type / method / import / etc
  • unresolved names (using a name that is not defined inside the context)
  • numeric format conversions (octal / hexa / decimal)
  • string format conversions ( raw -> normal and viceversa )
  • import optimizer
  • automatic importer
  • TODO

• proper internal formatter implementation that matches the go fmt tool

• proper $GOPATH support via either modules / libraries

• build tags support ( target config -> change the package composition and/or show what kind of config would include the current file)

• Google App Engine support (build / test / upload / etc)

• proper test framework integration with display in the IDEA go runner and click to navigate from results.

Extras

• method / function / type / variable renaming

• method / function / type / variable search usages

• type inference for expressions (this enables a whole host of inspections like)

  • invalid parameter type (with quick fixes to cast variables)
  • invalid index in index expression (with quick fixes to cast variables)
  • type of var x doesn't implement interface I (with quick fixes to implement missing methods)
  • method can be removed from interface (not used by the interface clients)
  • type T can / should be converted into an interface (go seems to favor interface declaration over explicit types)
  • move method M1, M2 into an internal package (hey aren't used outside of the package).
  • [idea] potential co-routines and channel usage issues: channel used after close, channel not created, etc
  • [idea] various inspections related to method values / method expressions
  • [idea] detecting if a var can be a constant or the other way around (change a local const into a var if used inside an assignment)
  • TODO

• dynamic expression type support (when x is assigned from an expression with a type T' which is a specialization of T the compiler will consider it as having type T' after that. This requires some var flow control analysis.

• debug support (as much as possible given the state of debugging in go)