Formatter options

[ematipico]

Description

Our formatter is now stable enough and I think we can start a discussion about what options our formatter should support and why. Also, we should put in place some requirements of when a new option is eligible for implementation or not.

[ematipico]

Options

At for now, our formatter support three options:

• indentation style (space, tab)
• line with
• number of spaces when indentation style is "space"

Other formatters have many more options and the question is: should we support them? If so, why?

[ematipico]

Here's my personal take. Formatters are here to remove the bikeshedding that we had in the past about coding style. By removing this bikeshedding, people can focus more on real code instead.

If we decided to introduce too many options, this bikeshedding might start again because people would love to have their coding style.

I believe that space/tab is a reasonable option because it involves accessibility. Line width too. On the other hand I think a rome project should have the same style.

[minecrawler]

If we decided to introduce too many options, this bikeshedding might start again because people would love to have their coding style.

I'd love to see (no hindrance for adding) many options, simply because I like my style, and others like their style, and I can simply run a formatter on git checkout to convert the code base to my style, and run it again before a git commit to convert code back to the common code style of the code base - so the common style does not bother me at all.

Also, I can keep my style config for any number of projects, so I don't see how having many options could lead to trouble on a personal level. Unfortunately, there is no central style guide for most programming languages, so each project would still need to agree on a common style, which is the place where I could see possible bikeshedding, but at the same time I would expect the formatter to come with sane defaults (common/best practices), so that ideally a project could live without configuring the formatter to produce good looking code, while I still keep my personal settings.

By doing so, the discussion about style can quickly be put to rest, and people can feel comfortable with what they are doing. If possible, I would love to see first class support for this kind of workflow (support several style-settings, e.g. as command-line argument).

One more aspect to keep in mind: Some tools outside of Rome may have non-configurable options or company-defaults which Rome should support. Different version control systems may e.g. have different EOL requirements.

---

Just for discussion, here are more options I see being argued over from time to time online (Hashnode / dev.to) and in my teams:

Common

• EOL markers (\n vs \r\n)
• EOF blank line vs no blank line

JS / TS

• semicolons at the end of statements or not (some people seem to see this as a tabs vs white-spaces kind of discussion)
• single quotes or double quotes (also in different contexts)
• brackets on a new line or not (e.g. function foo() { vs function foo()\n{)
• blank lines as first/last line in a class / method / function or not
• ternary operator on the same line or each branch on a separate line
• variable declaration as comma-separated list (one line or multiple lines) or each one with a new const / let identifier on a separate line
• blanks around brackets, operators, etc. (e.g. function(){ /* ... */ } vs function () { /* ... */ })
• trailing commas or not
• arrow functions styling: with parentheses or not, with brackets or not, new line after double arrow, etc.

HTML

• inner content (HTML or text) must be on a new line vs. can be on the same line as parent opening/closing tag
• number of attributes from which on each attribute should get its own line
• brackets on new line or not (when attributes are written on separate lines)

CSS

• brackets on a new line or not (e.g. html { vs html\n{)
• blank lines as first/last line of a rule

[ematipico]

I am already overwhelmed by the huge number of options 😅 a the formatter should have, as you suggested, same a reasonable defaults (good defaults!) and give the chance to change things that are really important.

My concerns is that the formatter should not become another webpack, where it's full of options. Or dprint: https://dprint.dev/playground/#code/Q/language/typescript (too many options IMHO).

So where's the line? Where does a style makes sense or not? Formatters are good because users should not bother about styling anymore.

Different version control systems may e.g. have different EOL requirements.

This is something we should consider 100%. Rome should not get in the way of other tools, if possible.

[ematipico]

Eligibility

Rome should be inclusive and accept any new suggestion from anyone, although we have some kind of eligibility process, some requirements

[ematipico]

I think an important requirement for options, to be eligible, is the accessibility factor. If an option doesn't help accessibility, should we even consider it?

[minecrawler]

Are all options accessibility related? Like the number of white-spaces, how are they relevant? I think that new options should not hinder accessibility, but don't need to be a helping factor at the same time ;)