True, though that seems to be duplicating the places it is accessed (it is used outside of the module), which although no duplication of information, does mean I have to jump to two places if I'm going to it (click on the function word once, then click on the attribute word), while adding lines of code. Seems like a needless workaround when the code as it is, is perfectly clear and sensible for what it does?
That has always bugged me as well. ^.^;
And as such, I do the exact same thing, every single one of my
defstruct's always use the list format, always (and this is a big reason why I always use lists for keyword lists in functions even if the
] is optional, it is because it fixes the durn comma issue). ^.^
Actually the consistency is context-dependent. Just because I may like lists to be one-element-per-line 99% of the time, not all contexts will that work well in, like for the multitude of math tables I have sitting here, math is a different context than normal code.
Not so for many of us, like I quite often will select a few lines of code and hit F4 to perform a Natural Sort on those lines, like with deps in mix.exs to just about every map's key/value's I write in normal code to others, and the trailing comma vanishing actually breaks the code then.
I'd primarily use it on a lot of the table-like stuff. ^.^
Exactly this, especially with tabular data, information tables, etc...
Very good point. Even though I use the clang-formatter in C++ I still write my code as I expect it to be read purely as well (and thankfully it formats near identically to how I write it, and I turn it off for areas that it breaks).
That is why I like following the rule in Elixir that I did in Erlang. ^.^
- If the bodies are short in all functions (especially single-liner's), 0-lines between heads.
- Else 1-line between each head.
- Always 2 lines between different heads.
- 2 lines, then a line of a comment with a header, then a blank line to separate sections (like trivial internal Helper functions at the bottom of a module or genserver public interface vs callbacks, etc...).
Which I'd have to unquote in place (and
Macro.escape/1 it as well), which either balloons the function making it more unreadable or I have to move out elsewhere, which removes its definition from it's public interface, which is always bad for a pure data structure (good with code). In addition this way makes it trivial to copy/paste between my C++/Python/Erlang/Elixir projects as it changes and updates.
Well even with this I like what it mostly does, even the one-element-per-line lists is awesome (just needs trailing comma's so sorting it does not break as lines are added), it is just context-dependent areas where the format gives information to the reader that the machine may not necessarily care about, like tables or tabular data or so forth.
Thus even if being less 'aggressive' when it did finally do it, it would still break in the same way.
I'd think it's better to do it 'all' outright, but there really needs to be a way to control it in context sensitive areas, like instead of turning it off outright it would be awesome to tag a set of lines of code as a different context 'name', which a configuration file could have overridden options for so we could do something like disable list one-lining for math tables and disable space collapsing for tabular chunks of data and such, this would both name the area, which is documentation for 'why' it is formatted different, as well as control the formatting without disabling it entirely in that area, maybe even turn on more options like natural sorting of lines in a map for example (or a list even though that changes the AST, it is useful for keyword lists). ^.^