Code formatting tool (mix fmt?)

[Pierre Jambet]

Hey Everyone,

I've recently been doing a lot of reading about elixir, and am definitely enjoying the language so far. As many people pointing out before me, the community is very friendly and welcoming, which is amazing!

I was wondering what the thoughts of the Elixir community were regarding a tool to automatically format code, similar to Gofmt. I've never worked professionally with go, but every time I played with it, I always enjoyed not having to think about how to format my code and having a tool do it for me.

Coming from a ruby/python background, I've seen some many debates regarding the "best" indentation, 2 or 4 spaces?, or if we should or not include a trailing comma in a multi line Array(list)/Hash(dict), etc ... And as much as I enjoy those almost pointless arguments, I think there is a real value in having an official and standardized way of writing code.

I've seen the elixir style guide project, I think it's a great initiative, and my suggestion would be to integrate the rules described there, or in any other official documentation in a tool that would allow automatic formatting in every major editors, as suggested in the linked GH issue, it could be something like `mix fmt`

Cheers,

Pierre

PS: Sorry if this topic was already discussed but I couldn't find anything except this GH issue

PS2: I learned this morning that rust is doing this too with rustfmt, which to me is an interesting indicator that another fairly recent language is developing such a tool.

[Louis Pilfold]

Hey Pierre

If you want a quick and dirty solution you could write a shell script
that opens (neo)vim with the Elixir plugin installed, and have it run
`=G:wq`, which will format the file.
Having said that, the plugin's indentation isn't perfect, so it'll
probably require a little extra work from someone who knows vim-fu
better than I do in order for it to always do something you could use
as your standard.

On a related note, I'm one of the authors of the Elixir linter Dogma.
I think it'd be nice if Dogma could comment on your indentation, but
I've no idea how one programatically checks indentation, and I've not
even started looking into it. Knowledge and pull requests are very
welcome.

Cheers,
Louis

> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-ta...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-talk/2764312e-90cf-4af8-8200-6ace16c13018%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Pierre Jambet]

Hey Louis,

Thanks for your reply. I already use a similar setup, I'm using the vim-elixir plugin which definitely provides good automatic formatting.

I guess my original post should have been a little bit more detailed, but I was actually thinking about a tool that does a little bit more than just indentation, but more importantly that would be editor agnostic.

I haven't looked very closely but it's very likely that vim-elixir and emacs-elixir don't behave similarly, and what about people using textmate, sublime, atom, or any other editor, each plugin is very likely to be slightly different, especially for edge cases, and there might be more than one plugin per editor.

What I have in mind is a program that takes any input (text, files, directory), and spits out the "official" elixir formatted version, then each editor specific plugin would use the exact formatting rules.

Furthermore, having such a tool could go a little bit further, again a la gofmt, which provides some simple refactoring, sorts the imports alphabetically, etc...

I'm still a beginner in the elixir world, so I don't yet what exact specific feature this theoretical tool could provide, that's why I was trying to get more experienced elixir developers opinion and see if they could see a potential value with something like that.

What about you? Do you see any value in this or do you think that a linter + vim-elixir (or any other plugin) is enough?

I hadn't heard about dogma before, I'll definitely take a look at it.

Cheers,

Pierre

PS: Looking at how go does it, they have multiple small tools, gofmt, as mentioned in my original post, golint and go vet, not exactly sure what are the exact differences between all of those.

[Alexander S]

+1 for *official* formatting tool.
Writing Go code for a long time, gofmt is miraculous tool. Think about teamwork, newbies etc

[Sandesh Soni]

+1 for official formatting tool

These things can be taken care of.
1> Code indentation
2> Cleaning Whitespace; In empty line as well as at the end of non-empty line.
3> Blank line at the end of file.
4> Only one empty line between two functions.

[Onorio Catenacci]

So what are you guys waiting for?  Jose has always been very open to accepting community contributions!  Get on that so we have an official formatting tool!  You're the "they" in this case (as in "they should build an official formatting tool").

--

Onorio

[Chris McCord]

I am a strong -1 on an official code formatting tool. It's simply not needed and it harms creativity. Elixir allows you to express your code in different ways in different situations. Imposing strict formatting, officially, is not something that should be provided by core. If your team is helped by imposing strict formatting rules that's great, but see dogma and other libs that allow you to flag deviations from team standards. Perhaps these projects could be a good area for contribution.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/b09135a6-3cf7-4910-b687-5360f77cbe9e%40googlegroups.com.

[Eric Lathrop]

I'd love an official formatting tool. It saves so much wasted discussion time. I'd rather be talking about algorithms than artisanal white space.

[Sandesh Soni]

How feasible is this and what would be the strategy ?

So far I came across
1> Code.loaded_files
2> Setup.__info__(:functions)

# Is this Possible ? #

List_of_loaded_Files

|> Map_Each_file_and_get_modules

|> Map_Each_module_and_get_list_of_functions_macros_constants_as_code_signature

|> Map_Each_code_signature_and_get_code_block

|> Apply_Logic_and_Algorithm_on_this_code

|> Add_this_code_to_temporary_file

|> override_old_file

I have been exploring Elixir for last 2 weeks, correct me if assumptions are hypothetical.

--
You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-talk/CfYVmQpKPIw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elixir-lang-ta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/c3e30bf2-4f5e-4c0b-8b1b-e414bf5e2f04%40googlegroups.com.

[Pierre Jambet]

Thanks to everyone who chimed in, I'm super excited to hear everyone's opinions.

Onorio: I just re-read my two previous messages and I can't find how I would have suggested that "they" should do it. It definitely was not my intention as I totally agree there's no "they" here, simply a "we". As mentioned earlier my idea was to get a sense of what people in the community feel about something like this, not to ask them to write one.

Chris: Thank you so much for your feedback. Interestingly, I think this would help creativity (instead of harming it) as it allows everyone to focus on what I think really matters. I'm having a little bit of a hard time understanding how it would not be helpful, which is very likely due to the fact that I'm a complete beginner with Elixir, but to me a tool like this wouldn't have to take away the ability to write different things in different situations. Thinking about `do: ...` and `do end` for a function body, both could be allowed, but maybe there would be a warning when using `do: ` on multiline, or maybe this could be parameterized on a per project basis, just thinking out loud here.

Anyway my point is that I think this would make it easy to have a centralized source for guidelines on what idiomatic elixir looks like, something other tools can rely on, but it also wouldn't have to deal with every single edge case of the language. If some constructs are too specific, then tool could totally ignore them.

I think that's it's very interesting that we have conflicting views on the matter but share the same purpose, fostering creativity.

And at the end of the day, if there are a lot of different opinions, this could definitely be simply be a this party tool that lives outside of core.

Cheers,

Pierre

[René Föhring]

> Thinking about `do: ...` and `do end` for a function body, both could be allowed, but maybe there would be a warning when using `do: ` on multiline, or maybe this could be parameterized on a per project basis, just thinking out loud here.

This (together with things like "Only one empty line between two functions.") is basically what code linters and style guides are for. 

I am confident that Credo [1] and the beforementioned Dogma [2] will provide this functionality in the future!

But that's just my two cents.

-René

[1] https://github.com/rrrene/credo

[2] https://github.com/lpil/dogma

[Onorio Catenacci]

On Wednesday, December 16, 2015 at 11:19:46 AM UTC-5, Pierre Jambet wrote:

Thanks to everyone who chimed in, I'm super excited to hear everyone's opinions.

Onorio: I just re-read my two previous messages and I can't find how I would have suggested that "they" should do it. It definitely was not my intention as I totally agree there's no "they" here, simply a "we". As mentioned earlier my idea was to get a sense of what people in the community feel about something like this, not to ask them to write one.

My remark wasn't really directed at you Pierre.  It was more of a general response.

--

Onorio

[Richard B]

I think this is a great idea. I wrote Go for a little bit and really the only thing I miss is `go fmt`. Having debates around syntax is such a waste of time and is a big reason why the Go community has been able to build a lot of tools in a relatively short period of time. Coming from years of Ruby, I tend to think of "creative syntax" as a euphemism for "oh my god my eyes are bleeding." I would much rather creativity be applied to the solution underneath rather than at the surface level.

[Chris McCord]

I thought "creativity" might be spun negatively :) What I'm saying is my personal coding styles are fluid. I've changed styles a few times in different ways, and occasionally I try out different things to test my prior tastes, i.e. newline'd `do:` for a single lined function clause that needs more horizontal space, no parens on null-arity, always parens on null-arity, indenting a pipeline that assigns to a variable, etc. The only auto formatting I have ever needed is select-all + `=` in vim/emacs for tabbed alignment. Sanctioning what I can and can't write in Elixir is not the things I want the core tooling to be doing for me. If a team wants to adopt strict guidelines, we have credo and dogma for that (which we use at DockYard for our own team guidelines). Richard, I respectively reject the premise that `gofmt` is a main driver to the community's growth in tooling :)

--

You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/6b72ae94-ded3-46cb-8357-8d58e73a79ea%40googlegroups.com.

[Richard B]

On Wednesday, December 16, 2015 at 11:33:45 AM UTC-7, Chris McCord wrote:

Richard, I respectively reject the premise that `gofmt` is a main driver to the community's growth in tooling :)

Fair enough. My first foray into Go was late 2012 when there were a lot less Go users than there are now and I still remember being impressed at how much already existed. But I think you could be underestimating how much of a productivity boost these things can be:

• Going into any project written in the language and never having to adjust to another person's style 
  
• Joining another company/team/project and not having to hunt for a style guide and also ramp up on that style guide
  
• Never having the thought of "should I reformat this code?" cross your mind
  
• Focusing only on code design and not formatting during a code review (this can be automated by Rubocop/Credo/Dogma but do they automate making the changes, too?)
  

Those are really important to quickly getting a team of programmers moving. Way back when I was first learning Elixir (and still today) I spent a ton of time looking at the formatting of code I wrote. I know others have, too. That's a distraction away from learning the language. Now as someone who is spreading Elixir by getting coworkers interested, an overwhelming percentage of questions I receive are about formatting a function definition or whether a pipeline should be on one line or multiple lines and how it should be indented. I'd much rather be answering questions about OTP.

Go gets a lot of things wrong (that's why a lot of us are here!) but go fmt is something they really got right.

[Kevin Montuori]

>>>>> "cm" == Chris McCord <ch...@chrismccord.com> writes:

cm> Sanctioning what I can and can't write in Elixir is not the
cm> things I want the core tooling to be doing for me.

Amen to that. Then the documentation doesn't have to say things like:

"Formatting issues are the most contentious but the least
consequential."

then later:

"If you want to know how to handle some new layout situation, run
gofmt; if the answer doesn't seem right, rearrange your program..."

(from https://golang.org/doc/effective_go.html)

When you're hacking away at your code to satisfy the formatter you may
as well have stuck to Fortran.


k.


--
Kevin Montuori
mont...@gmail.com

[Booker Bense]

There is one huge difference between elixir and go. Macros.

The syntax of go is pretty much fixed in stone, the syntax of elixir is meant to 

be adapted to the problem at hand. A formatting tool makes a lot of sense

in the first case, it's a potential straight jacket in the second case. See the

with syntax in 1.2 as a perfect example of the moving target that is 

the elixir syntax. 

Personally, I agree with Chris. I think a formating tool is a fine if you want, but

I think a standard tool is not the correct approach. Or at least not at this 

time.

Also, the elixir style guide is still a work in progress. I don't think a "standard"

consensus style exists yet. 

- Booker C. Bense

[Saša Jurić]

I'll side with Chris here and cast a (strong) -1 on a core formatting tool.

In my opinion there are very few rules which should be automatically enforced. Other than uniform indentation and naming conventions, I can't really think of rules which work best in all cases. Many times I find myself using different styles in different places, and that's not because of the lack of discipline, but because I try to choose what works best for the particular code at hand.

For example, I tend to use two blank lines before/after a multi-clause, with a single line separating each clause. However, if all clauses are one-liners, then I omit the blank line between clauses, and put only one blank line before/after.

Usually I put do: on the same line as def, but sometimes I put it on the next line (indented). I do similar with -> clauses. There are probably many other inconsistencies in my own style, but those are usually deliberate. Making the code readable is more important to me than following some strict set of formatting rules.

Other people will have somewhat different preferences, and that's perfectly fine, as long as the code is still easy to follow.

Which is why I'm against the official Elixir formatting tool. Such tool would basically enforce the styling rules in every place, regardless of the particular context. Sure, I could always avoid using the tool, but then I'd really stand out from the vast majority of the code, and probably have to endure frequent complaints about not using the formatter.

IMHO, 3rd party linters should do this job. Each team can then decide whether they need such tool, and tweak it to their liking.

[Greg Vaughn]

I'll add my vote against a core formatting tool too.

When I started with Elixir over 2 years ago, things were in flux. Much of what would be considered "proper" formatting has changed. I learned a lot by experimenting and reading the code other people wrote. I certainly understand how a single "blessed" format could help someone new to the language, but I recommend reading various code; learn different ways to format/express the same idea; figure out how each way emphasizes something different; go forth and communicate to humans via the code you write.

Programs must be written for people to read, and only incidentally for machines to execute.
- H. Abelson and G. Sussman (in "The Structure and Interpretation of Computer Programs)

-Greg Vaughn

> --
> You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/3ff3ce62-fd94-4b32-b196-466966493e15%40googlegroups.com.

[adrian...@hushmail.com]

Eric Lathrop wrote: 

> I'd rather be talking about algorithms than artisanal white space 

Doesn't the Go fmt package use elastic tabstops?

http://nickgravgaard.com/elastic-tabstops/

Aidy