Swiftlint: Specify line to highlight in Custom Rules

Created on 24 Apr 2017  路  4Comments  路  Source: realm/SwiftLint

Is there a way to specify the line that should be highlighted when defining custom rules? It seems like it's always simply highlighting the line where the regex match begins, but that's sometimes very confusing. Here's an example use case:

I have this custom rule:

custom_rules:
  vertical_whitespace_closing_braces:
    included: ".*.swift"
    regex: '\n[ \t]*\n[ \t]*[)}\]]'
    name: "Vertical Whitespace before Closing Braces"
    message: "Don't include vertical whitespace (empty line) before closing braces."
    severity: warning

And this code:

class MyClass {
    func someMethod() {
        // some code
    }

}

Currently the warning shows off in here:

class MyClass {
    func someMethod() {
        // some code
    } // <-- WARNING: Vertical Whitespace before Closing Brace Violation: Don't include vertical whitespace (empty line) before closing braces.

}

This is very confusing though as the rule actually refers to the second closing brace. Thus, the following would be better:

class MyClass {
    func someMethod() {
        // some code
    }

} // <-- WARNING: Vertical Whitespace before Closing Brace Violation: Don't include vertical whitespace (empty line) before closing braces.

I imagine that one could use a capture within the regex to give SwiftLint instructions which part of the match should be highlighted, for example my regex from above could then be:

    regex: '\n[ \t]*\n[ \t]*([)}\]])'

But I'm also open to other solutions. For example one could also say that everything enclosed in (?:regex) could be ignored when it comes to highlighting. This way the regex would look like this:

    regex: '(?:\n[ \t]*\n)[ \t]*([)}\]])'
enhancement wontfix

Most helpful comment

We could implement this with capture groups and then adding a new option like capture_group which would be the index of the capture group.

IMO this will not be something that people use all the time, but can be valuable for those who need it (especially since we don't have a plugin system).

All 4 comments

Is there any opinion on this issue? Is it too hard to implement? Not important enough? What's your thoughts, would be great to hear some feedback. Thanks in advance!

We could implement this with capture groups and then adding a new option like capture_group which would be the index of the capture group.

IMO this will not be something that people use all the time, but can be valuable for those who need it (especially since we don't have a plugin system).

While an actual implementation of this would cover more cases, it is currently already possible to exclude specific parts of a regex from the marker by using Regex Lookarounds.

Using my above example, the regex would be changed from

\n[ \t]*\n[ \t]*[)}\]]

to

(?<=\n[ \t]*\n[ \t]*)[)}\]]

As you can see I just placed the part which should not be marked into the lookbehind structure (?<=PATTERN). But the problem is, that lookbehinds are limited and actually the above example doesn't work, it's an invalid regex pattern since it includes variable width subexpressions.

Therefore, with a lookbehind, we can't really fix this issue (which is why it should be implemented at some point) but we can still improve our regex to this, which is valid:

(?<=\n)[ \t]*\n[ \t]*[)}\]]

This will at least make sure that in cases where there's no empty newlines right before the second closing brace the warning will be shown at the right place, like here:

class MyClass {
    func someMethod() {
        // some code
    }
} // <-- WARNING: Vertical Whitespace before Closing Brace Violation: Don't include vertical whitespace (empty line) before closing braces.

This issue has been automatically marked as stale because it has not had any recent activity. Please comment to prevent this issue from being closed. Thank you for your contributions!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jcarroll-mediafly picture jcarroll-mediafly  路  3Comments

SolaWing picture SolaWing  路  3Comments

Tableau-David-Potter picture Tableau-David-Potter  路  3Comments

bourquep picture bourquep  路  3Comments

ziryanov picture ziryanov  路  3Comments