-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Add new indentation_width rule #2765
Conversation
1a0a6e5
to
b83fb1e
Compare
Any thoughts on this? ;) |
b83fb1e
to
4b4c03e
Compare
As I'm personally not that active in reviewing other people's PRs, I'm certainly not in the position to complain that, seemingly, nobody wants to review this. However, I'd still like to see this merged at some point. Don't be scared by the |
2407a14
to
4f9d607
Compare
71dda8d
to
5fe042e
Compare
@jpsim Would you mind having a look here? ;) |
953b526
to
9947575
Compare
Anyone? |
8e49e17
to
693aace
Compare
7a628f2
to
4ddd3c1
Compare
4ddd3c1
to
2287fc8
Compare
2287fc8
to
5fc91e3
Compare
5fc91e3
to
3cd0d15
Compare
Rebasing this every 3 weeks or so is getting frustrating... If nobody has time to review this, maybe one could give me push access so that I can self-review and merge thereafter... |
0031f23
to
3e36ca7
Compare
@marcelofabri Would you mind having a look here? |
68a5652
to
b849922
Compare
Sorry for the lack of communication here @fredpi. I don't have a whole lot of time for OSS work lately 😞 I've given you commit access to the repo. In general, you should feel empowered to merge PRs to SwiftLint if other maintainers aren't being responsive. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great rule 💯
… one single issue
cb44955
to
6b40558
Compare
6b40558
to
c806942
Compare
It's been a while since #227 has last been discussed and it seems that an advanced indentation rule is somehow also pending some clarification on Xcode's side. However, since this issue has been open for such a long time, I thought about adding a basic additive indentation rule that only does the following things:
n
spaces indented (wheren
can be configured viaindentation_width
) or unindented keeping the grid.This PR implements such a basic rule. I tested it with a large project we have in our company and found out that it matches the indentation style we already pursued before:
However, this rule won't be compatible with other indentation styles like the one Xcode does by default and that is enforced by the
vertical_parameter_alignment_on_call
opt-in-rule:That's why this is an opt-in rule. As such, it won't do harm to those following another indentation style, yet enable built-in indentation linting for those who follow this basic additive pattern. Previously, we had implemented such a rule using multiple regexes that checked for indentation but didn't always work properly, so having this built-in is definitely a plus.
I want to mention that, according to this rule, unindentation can not only be done by one step (~
indentation_width
spaces), but also by multiples of one step. This is to allow for the following indentation which I consider valid: