-
-
Notifications
You must be signed in to change notification settings - Fork 927
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
New rules: block-opening-brace-before and -after #18
Comments
For this and most of the other whitespace-related ones --- do we want to leave the whitespace entirely open-ended, or just give the keyword options "space" and "newline"? Do we imagine scenarios when somebody might want to do something weird like use 4 spaces, a tab, 2 newlines, a carriage return, etc.? It would certainly simplify things if we only had "space" and "newline" as keywords for the options ... Thoughts? |
Disclosure: I'm kind of leaning towards keywords myself, because it makes things much simpler and I have this sense that anything other than space/newline is a serious edge case ... |
Go simple indeed ! |
Agreed. |
I'm throwing out the single- vs multi-line distinction for this rule unless somebody requests it. It would add significant complexity that I would rather not build in for a questionable use-case. The only use-case I can think of is a styleguide that wants this: body { color: pink; }
a
{
color: pink;
background: orange;
} But I think pretty much everybody would prefer consistency before that brace ... either: body { color: pink; }
a {
color: pink;
background: orange;
} or: body
{ color: pink; }
a
{
color: pink;
background: orange;
} ... since I think the only reason to have a newline before the brace is to clearly demarcate the selector |
Agreed. I think you're totally right to avoid questionable use-cases until they are request. Lets keep things as simple as we can to begin with :) |
I will work on this.
The text was updated successfully, but these errors were encountered: