The Elixir Style Guide

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

+1 on merging with Credo, that way we’ll have sane defaults and suggestions out of the box if we use Credo (just like Elm did with elm-format, while not exactly a linter).

Well, unless if that’ll make the styleguide less “by community”.

Originally the suggestion might have gone the other way around. The Elixir Style Guide has quite a few more rules/ideas than the one for Credo, and it’s not clear they would all fit in there, as a “personal style guide.”

But there’s no reason we shouldn’t work together and share ideas and benefits.

It would be better if we merge them and ping @josevalim to approve as “Official Elixir Style Guide”. In atom-beautify is issue to Add support for Elixir #545. It would be much more easier to maintain support (also for Credo project) for official style guide instead of multiple style guides that could conflict now or in future. How to fix conflicting rules if we don’t have official approve? So it could be going to solve possible conflicts in different way for each project that depend on it and this may cause problems especially for Elixir beginners.

As a word of caution, I wouldn’t hold out for an “official” style guide or expect that the core team would want to maintain this kind of thing.

But it would be great if someone would detail where the style guides diverge. We also shouldn’t be quick to dismiss a plurality of styles.

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

Thanks for weighing in @josevalim. The style guide from @lexmag is also really great. I’m not sure anyone wants to settle on one thing at this point. My feeling is that any “official” guide would focus on the minimal set of conventions, whereas the style guide I linked to can afford to be both broader and more detailed.

But I also get that a lot of users want something simple and easy to apply, which is where Credo maybe comes in.

@josevalim: Nice to see that we already have a style guide that is accepted by core developers! Of course merging @christopheradams style guide and Credo style guide at now is not needed.
Last thing is to ask if @lexmag and/or other contributors are looked at other style guides and express opinion about possible differences between them and @lexmag version. There is a possibility that in the other style guides appear rules and/or exceptions for existing rules that could/should be accepted.

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.

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.