-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
opening_braces allows some multiline if statements, others get flagged #5923
Comments
I'm unable to reproduce this issue. Both examples trigger with version 0.57.1 on my side. With the option |
You are correct. I tried to create a simple test file but in that case every attempt generates the error. While I had read of that new rule you mentioned, it's not in the documentation file, so I was unsure it was actually implemented (of course today on a deep search I see it added to the announcement of 0.57.0). Can you re-use this ticket so that it gets added to https://realm.github.io/SwiftLint/rule-directory.html? If so I'll edit the title. |
It's not a rule but an option of |
Documentation for those options would be super helpful, but again understand this is a volunteer effort. Thank you for responses here and sorry that I wasted your time with the initial issue. I thought I had verified the one non-complain but obviously I had not. |
Adding documentation for the various options of all rules is a long term effort, but definitely desired. At the moment, though, there's no infrastructure prepared to do that. |
It could get added to the page on open_braces itself. I looked but there is no way to contribute to the project. I'd gladly fund someone to add additional documentation on all those opens to open_brace, as this issue I reported has generated a lot of discussions in my company. What we would really like is a way to only allow the brace to appear after the predictates on its own line. Turning on ignore_multiline_statement_conditions opens the door for much more. Would it be unreasonable to request "allows_single_brace_on_its_own_line_for_multiline_predicates"? Could we fund that effort? |
The documentation is fully auto-generated. One cannot just add manual comments afterwards. That's why I mentioned the need for the right infrastructure first.
What would be the difference between |
Again, thank you so much for engaging with me in this ticket! The contrasted_opening_brace is absolutely not what we want! Our coding style should allow: and disallow if a The sole reason for ignore_multiline_statement_conditions is that we want he brace on a new line ONLY if there are more than one conditions in the for loop: if and probably if a, Our issue with ignore_multiline_statement_conditions is we don't understand what other side effects setting this does. Will it let developers do crazy things if there multiline conditionals and a brace? I didn't try but guess I could, is this now allowed if Even the google style guide requires that open and close braces be at the same tab stop if the are preceded by a multiline conditional. |
So your point is that you don't just want to ignore braces after multiline conditions but enforce them to be on their own line. Correct? |
Yes, but more - they must vertically align with the "if" statement. |
New Issue Checklist
Bug Description
Related issues: #5521, #5602
Some multiline if statements with a starting brace don't trigger an error, but more complicated lines do. For instance no warning:
More usual code triggers an
opening_brace
error:Environment
Are you using nested configurations? If so, paste their
relative paths and respective contents. N/A
The text was updated successfully, but these errors were encountered: