Permalink
Fetching contributors…
Cannot retrieve contributors at this time
18 lines (10 sloc) 2.28 KB

Organize imports Refactoring

The organize imports refactoring takes a module and simplifies the import list. The import list will be cleaned of unused imports and sorted alphabetically.

As a haskell module changes, new imports are added to it, but unused imports are rarely removed. This leads to a lot of unused imports that clutter the source code and misdirect the developer who tries to figure out the dependencies between modules. This refactoring resolves the issue automatically, removing imports that are not necessary, and ordering them alphabetically, to move them into a conventional format.

When the refactoring orders the imports it respects import blocks (list of imports that are separated by an empty line). This way the programmer can still categorize the imports into groups that should not be mixed, but the imports inside the groups will be sorted.

If the list of explicit definitions stated in the import contains definitions that are not used they are removed. The same is done for sub-specifiers of these imported definitions (for example constructors or fields that are imported as a part of the type defining them).

If an import definitions only brings to scope at most 4 definitions, they will be explicitly stated in the import definition.

Import definitions cannot always be removed even if no definitions are used from them. They may be used to import type class instances. If the refactoring cannot prove that there are no such instances, it only states that no definition is used by putting empty parentheses after the imported module name.

There are some extensions and language elements preventing the safe usage of the refactoring. In these cases the refactoring is fully or partially disabled.

  • If TemplateHaskell or QuasiQuotes is enabled, we just reorder the definitions, but don't check if they are used or not. Code generated by splices or brackets can use arbitrary imported definitions, so narrowing the imports is not safe.
  • If StandaloneDeriving is used, or foreign functions are defined the sub-specifiers of import declarations are not removed even if not used. These language elements generate code that will implicitly use imported constructors. If FlexibleContexts is enabled than the narrowing of other imported definitions would not be safe, so it is disabled.