@lexmag, from Elixir, maintains a style guide mostly aligned with Elixir source: https://github.com/lexmag/elixir-style-guide. If we are ever going to adopt something as official, which is unlikely, that one is the most likely.

How about merge this guide with: Credo’s Elixir Style Guide and add issue to Credo github project?

For some things it can clearly be seen that one kind of writing will be less error-prone than another.

But in many other cases, the exact method used is not as important as that you (and your team) are consistent: Things like tabs vs. spaces, order of pattern-matching in parameters (x = %{} or %{} = x?), names given to exception classes, et al. I really like Credo’s approach of saying “It doesn’t matter which one you like best, but pick one and stick with it”.

I think it is great that we have multiple style guides, because this means that people will stay conscious about the choices w.r.t style they make.

I think that right now we do not need an officially endorsed (or enforced) style guide, because Elixir’s syntax itself is already a great tool to help developers write reasonably readable and consistent code.

Since Credo was mentioned, I’m not aware of anything in the Elixir Style Guide that contradicts it. (We might however be missing a few rules that we should fill in.) I think you should be able to follow any of the style guides and get Credo’s linter to pass.

However, we also have some guidelines that will probably never make it into a linter, such as how to organize your module attributes/directives.

As long as you’re enjoying Elixir and sticking to a style you’re doing well!

Having tried go before, I’d just really like to leave my 2 cents here:

Go imposes a style guide, which I found a bit awkward at the beginning but then grew in me as I found it very liberating. Style is one of those things that’s a bit pointless to discuss, any sensible option is more than good enough.

Anyways, forcing a style does have quite a few good things, especially if it comes:

• No pointless discussions about what one should use.
• Every repo is just like your own code.
• You can easily automate it.

I do agree with @christopheradams, if an official style guide is enforced (and the tools to do so are built) it needs to be something minimal and to the point rather than a complete style guide.