Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Presets #185

Open
lassik opened this issue Sep 20, 2018 · 1 comment
Open

Presets #185

lassik opened this issue Sep 20, 2018 · 1 comment

Comments

@lassik
Copy link
Contributor

lassik commented Sep 20, 2018

@muuvmuuv wrote in #184:

Additionally we could do something like:

"extend": [
"/Users/marvinheilemann/Documents/Configs/.unibeautifyrc.json",
"unibeautify:recommend",
"unibeautify:prettier"
]

so users could use presets defined by the community? unibeautify:prettier would then use prettiers default config for all languages. This would also mean we need a for all langauge tag like * or _.

I would be in favor of having presets for some well-established styles. For example K&R for the famous Kernighan and Ritchie style for C-like languages. Replicating the individual settings by hand to achieve a particular style is a big effort.

On the other hand, if there are a ton of presets, or some not-very-popular ones that just happened to be convenient for the developers, then it becomes hard as a user to pick the one you want. For example, the current preset list of clang-format is: LLVM, Google, Chromium, Mozilla, WebKit. This is not the list of the most influential C styles ever - it looks more like the developers just added the ones they personally needed. Some of those styles are very similar to each other.

So I would be in favor of having a carefully curated list of presets that emphasizes:

  • Popularity
  • Longevity (styles that have been popular for e.g. a decade, not just led by one trendy project)
  • Variety (e.g. one with 2-space indents, another with 4-space, another with 8-space/tabs), avoiding styles with only minor differences.

But that's just my opinion.

@lassik
Copy link
Contributor Author

lassik commented Sep 20, 2018

A couple other points:

  • If we have an extend/inheritance mechanism (Option to extend another unibeautify config #184) then styles that are quite similar to a classic style, with minor differences, are quite easy to specify by giving the classic style as a preset followed by a few overrides for the settings that are different.
  • Having only classic presets is a small nudge to encourage people to stick to them, instead of making countless minor variations. On one hand, it's great to have options, on the other hand it fuels bikeshed discussion and can add friction for devs switching between projects. Compare to the license proliferation situation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants