Add SwiftLint rule to prevent multiple variable declarations on one line #5990
Conversation
|
Thank you for the contribution! Here are some general remarks:
|
|
Thank you @SimplyDanny, yes it was unnecessary to have unit tests for it, I think now it'll work properly. |
Danger doesn't like merge commits, that's all. You need to rebase your branch onto |
|
@SimplyDanny I'm trying to rebase on main but I'm afraid of messing everything up actually, as there is conflicts while rebasing and I'm afraid of not including your changes 😬 |
You definitely messed something up. You can try to rebase again and throw away all commits that are not yours or duplicates of commits you have created previously. There shouldn't be any conflicts apart from maybe CHANGELOG.md, which would be easy to resolve. |
AhmedZaghloul19
force-pushed
the
multiple-variable-declaration-rule
branch
3 times, most recently
from
25b3805 to
7f6556e
Compare
AhmedZaghloul19
force-pushed
the
multiple-variable-declaration-rule
branch
from
7f6556e to
92b6a81
Compare
@SimplyDanny the git now is fixed and everything is ready 👍🏼 |
Commits look okay now. But there's still a few things to consider. Did you read my other comment carefully? |
|
@SimplyDanny Now it's ready, but I think it's not good to merge with the 436 warnings which is the violations of the new rule in the project. |
There was a problem hiding this comment.
This looks much better! However, there are a few more remarks from my side ...
Now it's ready, but I think it's not good to merge with the 436 warnings which is the violations of the new rule in the project.
do you think we have to fix it in this PR or create another issue for creating that and I'll do it also ?
These warnings are from other project, we scan to get an impression on the rule's behavior in the real world. It's fine to have many warnings as long as they are valid. It shows that the rule does a good job in finding violations. Important is that all of these findings are actually valid and (if possible) no false positives. This is what you should ensure.
Source/SwiftLintBuiltInRules/Rules/Idiomatic/MultipleStatementsDeclarationRule.swift
Outdated
Show resolved
Hide resolved
Source/SwiftLintBuiltInRules/Rules/Idiomatic/MultipleStatementsDeclarationRule.swift
Outdated
Show resolved
Hide resolved
| private extension TokenSyntax { | ||
| var isThereStatementAfterSemicolon: Bool { | ||
| guard tokenKind == .semicolon, | ||
| !trailingTrivia.isEmpty else { return false } |
There was a problem hiding this comment.
I don't comprehend this condition. Why is no trivia after the semicolon allowed? I think an example like let a = 0;let b = 0 should trigger as well.
| isFollowedOnlyByWhitespaceOrNewline { | ||
| return nextToken.leadingTrivia.containsNewlines() == false |
There was a problem hiding this comment.
I think what you actually want to know is whether the next token is on the same line as the semicolon. You can use locationConverter in every visitor and rewriter. It can tell you on which line a certain token is located. If you compare the line of the semicolon with the line of the next token, you know whether to trigger a violation or not.
| if Date().timeIntervalSince(startDate) > timeout { | ||
| task.cancel() | ||
| break | ||
| } |
There was a problem hiding this comment.
This doesn't look like it got auto-fixed by the rule. The only cases that can be fixed automatically are the ones where the statements are on their own line without leading tokens. We should probably restrict the rewriter to these cases.
| let newNode = TokenSyntax( | ||
| .unknown(""), | ||
| leadingTrivia: node.leadingTrivia, | ||
| trailingTrivia: .newlines(1), |
There was a problem hiding this comment.
This doesn't indent the following statement. Consider the example
{
let a = 0; let b = 0
}which should be corrected to
{
let a = 0;
let b = 0
}There was a problem hiding this comment.
The autocorrect version is
{
let a = 0
let b = 0
}
as we're removing the semicolon, as it's swift code styling
We can keep the semicolon as well
There was a problem hiding this comment.
Correct. My bad. Except this example wouldn't be formatted like that with the current implementation.
…sDeclarationRule.swift Co-authored-by: Danny Mösch <[email protected]>
for the issue:
Rule Request: Avoid multiple statements on a single line separated with semicolons #5829