Ordering Use, Import, Alias, Require?

Questions / Help
,
1

Is there a recommended ordering of require, use, import, and alias? Does the style guide have anything to say about the preferred ordering of special forms?

2 Likes
2

Nevermind, the styleguide is pretty explicit about this: GitHub - christopheradams/elixir_style_guide: A community driven style guide for Elixir

List module attributes and directives in the following order:

  • @moduledoc
  • @behaviour
  • use
  • import
  • alias
  • require
  • defstruct
  • @type
  • @module_attribute
  • @callback
  • @macrocallback
  • @optional_callbacks

Add a blank line between each grouping, and sort the terms (like module names) alphabetically.

16 Likes
3

Note that the order of some items have been changed:

  1. @moduledoc
  2. @behaviour
  3. use
  4. import
  5. require
  6. alias
  7. @module_attribute
  8. defstruct
  9. @type
  10. @callback
  11. @macrocallback
  12. @optional_callbacks
  13. defmacro, defmodule, defguard, def, etc.
18 Likes
4

Does anyone know if mix format takes care of this somehow? Any config I can set to have it auto sort it for me?

5

I don’t know if it handles ordering all of them but might be able to be extended to do so.

https://hexdocs.pm/recode/Recode.Task.AliasOrder.html

6

It won‘t ever do that. One premise of the core formatter is that it won‘t change the underlying AST by applying formatting. That ensures that formatting will never introduce a change in behavior of the code and therefore won‘t introduce unintended bugs. Reordering expressions means changing the AST however.

4 Likes
7

Sound decision, makes total sense. I wish it would reorder still :laughing:

I guess I’ll configure Credo to be extra annoying so my team doesn’t commit unordered aliases. credo --strict --no-really-i-want-strict

8

Sorry, I meant recode, not the formatter, when I said “it”.

9

I wonder if anyone is using the following:

  • alias
  • import
  • require
  • use

So you can just sort the whole thing alphabetically, without empty lines.

An only after that module attributes, including @moduledoc, as in the doc I found quite often useful to be able to reuse another attribute, or even call a remote function.

1 Like
10

At my place we do not have a strict order, as long as they are grouped accordingly.

Though due to the way our set up is structured, we often have calls to use/2 in a certain kind of modules that set up “dependencies” to other modules of the same kind input and output events. Those uses were really ugly to write with the regular “use first” rule, and we eventually got into the habbit to generally have aliases first, uses second. require just follows that. And we generally avoid import.

1 Like
11

Depending on what they are and the “type” of module, I put them close to where they are first used. If there is a single errant function that needs a macro, I require or import it right in that function.

1 Like
12

Folks who would like a more aggressive tool for this might want to look into Styler. It is opinionated and explicitly doesn’t promise that it’ll never break your code, but IME it usually doesn’t and I really do value the automated fix-ups.

As a simple example, sometimes I start writing a pipeline and then realize there’s only one function in it
 If I save the file with auto-format enabled in my editor, Styler will automatically un-pipeline the call.

1 Like