Crystal: Crystal tool format should be more opinionated

Created on 3 Apr 2020  路  9Comments  路  Source: crystal-lang/crystal

The current cyrstal tool format doesn't have much of an opinion about formatting of list-like structures, e.g. Hash, Tuple, Array, Method arguments, ...

For example all of these method calls are untouched by the formatter, leading to very inconsistent styles:

foo(bar: baz,
  foobar: foobaz)
foo(
  bar: baz,
  foobar: foobaz
)
foo(bar: baz, foobar: foobaz
)
foo(
  bar: baz, foobar: foobaz
)
foo(

  bar: baz,

  foobar: foobaz,
)

Similar examples could be given for most of the literals containing multiple values, and even if you write them all on one line, the formatter will not enforce a maximum line length, so you still have to go in and do a lot of manual work.

I'd really appreciate a formatter that reduces creative freedom to a minimum to let me just focus on writing the code and not spending that much time on making it look consistent, even if it's as a separate tool.

This is on Crystal 0.32.1 on NixOS.

discussion topicformatter

Most helpful comment

Mandatory Gif, #Sorry :-)


Formatting arguments is hard. Sometimes there is a subtle relationship between them and once want to give some spacing for clarity, or join two in a same line while leaving the rest appart.

I'm ok to letting that go, but, in my experience I usually use some custom formatting. The elm-formatter has some heuristics regaring if arguments should be all in one line or separete ones, but I don't find that enjoyable the formatting choice there in some invocation.

That at least is my experience.

All 9 comments

I think there are a few other related issues to this. I have opinions on this myself and appreciate the division the Crystal community has come up with. If you want whitespace and basic formatting the Crystal compiler ships with that and if you want opinions that do more opinionated changes Ameba can be included in your project. This uses the internal compiler components including the parser to help format the code. @veelenga is it's creator and gave a great talk at Chicago Crystal about Ameba.

Mandatory Gif, #Sorry :-)


Formatting arguments is hard. Sometimes there is a subtle relationship between them and once want to give some spacing for clarity, or join two in a same line while leaving the rest appart.

I'm ok to letting that go, but, in my experience I usually use some custom formatting. The elm-formatter has some heuristics regaring if arguments should be all in one line or separete ones, but I don't find that enjoyable the formatting choice there in some invocation.

That at least is my experience.

I'm very happy with the current scope of the formatter. It enforces some very basic format so we can enjoy a sane reading experience but istn't too opinionated on top of that. It still leaves a lot of freedom for different styles. Whether a style is personal preference, formalized style guides or specific to individual situations, you can still use it with crystal tool format.
If it was more opinionated we would lose people that don't agree with these opinions and they wouldn't use the formatter at all.

The formatter is actually pretty opinionated, it just supports multiple different ways of expressing lists of expressions

We have a formatter to end discussing styles. The idea is, you run the formatter on some code and that's the accepted style. That's where the discussions should end.

If you code it in a way and someone comes and say to you "but this should be in a separate line", you tell them "let's run the formatter". If it stays the same, there's nothing else to discuss.

Sometimes it makes sense to group arguments because they are related. Other times exceeding the column limit by just a little is fine. All of this is subjective. And it would be a pain if the formatter didn't give you that freedom.

There might be a plugin for your text editor to help you to split the arguments into separate lines, or join multilined argument together.

E.g., (neo)vim has a great [splitjoin.vim], which helps to solve that (among others) usecase.

If the method's text exceeds the width of your monitor, line breaks can be a good thing. Some developers like that, and some like a loooong line where they use horizontal scrolling.

Can we close this? I don't think there's going to be any change here.

Closing because it's mostly not wanted.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lbguilherme picture lbguilherme  路  3Comments

ArthurZ picture ArthurZ  路  3Comments

TechMagister picture TechMagister  路  3Comments

costajob picture costajob  路  3Comments

asterite picture asterite  路  3Comments