As said previously, we would like to play with other ideas in this area. The formatter has not had any kind of extensive usage yet, so we should wait and collect more feedback before doing more changes.
josevalim
Creator of Elixir
LostKobrakai
For me most functions do have documentation/typespec, which visually separates functions from each other and for private functions I’ve by now not felt the need, but would probably go with just a simple comment or typespecs where applicable.
1
sergio
Pardon my question but how do I use this Elixir formatter? Is it like go fmt in that it cleans up the code?
Do I need to have Elixir 1.6 installed? Is 1.6 production ready?
0
chulkilee
# install erlang with homebre
brew install erlang
# install asdf to manage Elixir versions
if [ -d "$HOME/asdf" ]; then
git clone https://github.com/asdf-vm/asdf.git "$HOME/.asdf" --branch v0.4.0
fi
# don't forget to add following part to your shell config (e.g. .bashrc)
. "$HOME/.asdf/asdf.sh"
# install elixir plugin if missing
plugins=$(asdf plugin-list)
if grep -q -v elixir <<< "$plugins"; then
asdf plugin-add elixir https://github.com/asdf-vm/asdf-elixir.git
fi
# install with asdf as in .tool-versions
asdf install
# install master version
asdf install elixir ref:master
# run mix format with elixir master
ASDF_ELIXIR_VERSION=ref-master mix format
I have mix_format alias in my ~/.alias
alias mix_format="ASDF_ELIXIR_VERSION=ref-master mix format"
7
NobbZ
Yes-ish, you need Elixir compiled from master, which is going to be 1.6.
It has not been released yet. Not even a release candidate. So, I do not consider it production ready. José once said, that 1.6 will probably released during Q1 '18.
2
thousandsofthem
Will something like
defining pattern
x y(different),...
x y(different),...
x y(different),...
in the formatter work?
0
OvermindDL1
A lot of it is for me too, but I already do a lot of what it does. I often separate function heads by a newline unless they are very short and are obviously blocked together, and I separate different head types altogether by 2 lines, and categories of functions by 3 lines with a (comment via ##) header then another blank line, which the formatter utterly destroys.
In addition, a lot of the baked tables I use become entirely unreadable. The formatter does some friggin-weird alignment on things like multi-line type declarations and wrapped maps/lists/tuples of things that just push things needless way right (wtf?). A lot of single expression function bodies get formatted very weird out onto multiple lines, making the whole structure horribly unreadable and multi-indentions deep (wtf?). It ‘does’ format a lot of my sub-blocks inside a function exactly how I already do it, so I like that more people will follow that style (I find it far more readable than what many people do). Overall it seems a good start but it does need some work, especially some way to mark a section as DO_NOT_FORMAT_THIS as it just breaks some things all to hell that require alignment to be readable, especially data tables, those just become wtf’s all around… o.O
Lisp has some very nice formatters, and nicely they work on any lisp style language. ^.^
Really though, if text was not so ubiquitous, editing source via a graph database or something would be awesome, you could make so many useful interconnections and such! Plus IDE’s would become practically trivial. ^.^
I will definitely be adding it to my macro string source debug output generation for sure! Convert all that horror of things like def(blah(x, y), do: 42) into actual usual looking code then! ^.^
I have no qualm with using up lots of space, I like space where it helps readability (like data tables and such), though I would really prefer tabs for indentation and spaces for alignment, always, spaces are not for indentation! o.O!
Yeah this is where I like to put heads together if the functions are very short, and separate by a single blank line if longer (using the same format for all heads of a function).
I do like this aspect of it a lot. ^.^
Yeah I do this same thing here quite a lot (except I had to set it to 3 for some reason that I forgot).
This is what I do!!!
Except for such short functions as you have there they’d have no blank lines between the heads and still have 2 blank lines between the different functions. 
I find this style of mine much more readable, and I’ve been using it across a lot of languages over a lot of years.
Hmm, comments could do the separation I seek, but that would add a lot of noise, especially as I use semantic highlighting in my IDE’s so the comments would end up just glowing out of the screen (in semantic highlighting comments are considered as ‘way important’, if they aren’t then you should get rid of them and make the code clearer instead).
I keep up to date with elixir master on my dev server and I have to say that the formatter makes a lot of my code entirely unreadable as it is… I tend to use many short functions when at all possible and pre-generated quick lookup tables and etc, yeesh… ^.^;
Wow that is a lot of work for that, I just do cd /opt/elixir; git pull; make; _make install… o.O
Although I’m not running different versions here, so eh… I’v not had master elixir break on me yet. ^.^
1
MrTortoise
yurko
I never really expressed how happy I am with the fact that elixir gets this formatter, so here goes: very happy 
The negative aspects that are voiced here mostly have to do with each of us having our own style of doing things and our own subjective opinion on what is “right” or “beautiful”. These are results of Elixir allowing all the different ways to write the same thing.
In my opinion the most important aspect of having the formatter is to reduce these options and make the code more consistent. I can live with the resulting format being different from what I use now as long as there is one true way used by most other programmers, libraries etc 
It should also help adoption in the non-ruby community.
Brackets are now applied automatically44 so no more dealing with those warnings. This is a big win.
that’s just pure 
2
mischov
Is there a place where reasons for formatting choices have been discussed, or an appropriate place to ask questions?
When looking through formatted code there are a few unexpected cases and it would be nice to understand how that choice was made.
This formatted map update syntax in particular is an interesting one:
%{
document
| id_counter: id,
nodes: insert_node(document.nodes, node)
}
instead of
%{document
| id_counter: id,
nodes: insert_node(document.nodes, node)
}
2