Ordering Use, Import, Alias, Require?

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

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.

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.

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

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

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.

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

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

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

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.

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.

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.