Crystal: Add configuration for Crystal format tool

[AlexWayfer]

Hello.

I want to configure `crystal tool format. For example, I want to indent by tabs and don't get offenses.

I think, the YAML file is most appropriate.

Thank you.

UPD: I don't want to change something (by default), I just suggest an option, flexibility, and there are down votes… OK.

[asterite]

Hi! Crystal formatter aims to have a unique format. The idea is to avoid discussing or spending time choosing some formatting option when the language already chooses one for you.

Of course, one is free to fork the formatter and provide external tools. But the builtin formatter will never be configurable.

[straight-shoota]

See also previous discussions like #5134 and #1682

[AlexWayfer]

The idea is to avoid discussing or spending time choosing some formatting option when the language already chooses one for you.

I think, the language should not chose any format for somebody, but if draw analogues with natural language (orthography, punctuation) — OK, maybe your approach is acceptable.

Of course, one is free to fork the formatter and provide external tools.

Should the built-in formatter be a shard? It'd be easier to fork.

But the builtin formatter will never be configurable.

OK, thank you.

See also previous discussions like #5134 and #1682

Thank you, I was finding, but have not find them.

[oprypin]

The formatter aims to make code look uniform everywhere, not necessarily to make it look nice.
And you can tell, because it definitely doesn't look nice 😂
Anyway, the thumbs down are because configurability goes against this main idea.

[asterite]

Also, this decision is similar to what gofmt, Go's formatter, does, and the reasons for doing that are also similar (avoiding discussions around code styles).

@oprypin curious, what doesn't look nice? (of course I know this is subjective)

[oprypin]

The single biggest issue I have is aligning lists (like enum) and comments with extra spaces.
But yes. Subjective.

[AlexWayfer]

The formatter aims to make code look uniform everywhere

I don't like uniform…

I know past societies with uniforms in previous century, for example, and they were not so good.

---

By the way, @asterite, please, answer, if it's not too hard, since we've started this subject:

Should the built-in formatter be a shard? It'd be easier to fork.

[straight-shoota]

... and Godwin's law strikes again.

Sorry, but this comparison is totally inadequate. Uniformity is not bad in itself. It avoids a lot of friction caused by superficial vanities.

Should the built-in formatter be a shard? It'd be easier to fork.

No. It's an integral part of the compiler. Maintaining it separately adds a lot of complexity and overhead which can be avoided. Aiding fragmentation of styles supported by the formatter tool is not a goal as per above comments.

You don't need to fork the compiler though. You can just reopen or inherit Crystal::Formatter to implement your own rules.

[AlexWayfer]

... and Godwin's law strikes again.

I'm not about only this social group, there were a few, but yes.

Sorry, but this comparison is totally inadequate.

It was not too seriously.

Uniformity is not bad in itself. It avoids a lot of friction caused by superficial vanities.

It's just different points with pros and cons, let's finish it. I personally like freedom and configurable. But I've got maintainers point.

No. It's an integral part of the compiler. Maintaining it separately adds a lot of complexity and overhead which can be avoided. Aiding fragmentation of styles supported by the formatter tool is not a goal as per above comments.

Sadly to read this, but OK, thank you.

You don't need to fork the compiler though. You can just reopen or inherit Crystal::Formatter to implement your own rules.

Yes, but it's harder to follow changes. OK.

[wontruefree]

@AlexWayfer have you seen https://github.com/crystal-ameba/ameba?

[AlexWayfer]

@AlexWayfer have you seen https://github.com/crystal-ameba/ameba?

No, thank you!