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
chore: swift lint cleanup #756
chore: swift lint cleanup #756
Conversation
* develop-upstream: chore: EIP681 docs + more descriptive log message fix: ENS parsing requires chainID if an ENS address is expected to be requested/decoded - we do not assume that client is using Ethereum Mainnet! fix: RLP func encode for single value has named parameter chore: test refactoring - checking for nullability by using XCTAssertNotNil chore: replaced [Any]() with [] for default parameter value fix: removed as AnyObject from ENS related code chore: removed spacing in `" )` fix: spacings chore: removed redundant `parameters: []` in read operation fix: EIP681 - when parsing arguments chain ID must be defaulted to Mainnet instead of 0 fix: Networks.fromInt must not return optional fix: some spacing and docs fixed fix: ERC20BaseProperties are back to inherit from AnyObject (restricting protocol to classes) fix: removed the use of AnyObject in all places possible - replaced with Any # Conflicts: # Tests/web3swiftTests/localTests/ABIEncoderTest.swift # Tests/web3swiftTests/localTests/TransactionsTests.swift
…ultiline function calls
.swiftlint.yml
Outdated
- type_name | ||
- identifier_name | ||
- line_length | ||
- multiple_closures_with_trailing_closure | ||
- todo | ||
- indentation_width |
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.
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.
Perhaps we should use swiftlint --fix
on this file to propose a solution that is acceptable to that tool. If that solution is also acceptable to project maintainers then we should go that way instead of disabling this rule. If all that succeeds then the code format will align with other swiftlinted projects.
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.
This rule has no autocorrection. Warnings appear on completely valid pieces of code.
Update: found the reason for this warning. We should not place the first argument on the same line as the function name. The code should be instead:
Not an unreasonable variation of indentation and style.
But it also applies to guard
statements (and likely not only). All conditions, if there are multiple, should take a separate line each and must not be on the same line as guard
keyword:
This variation is also allowed by the rule, but it's less readable and not pleasant to look at at all:
Based on these findings I'll re-enable this rule per @cclauss suggestion.
@yaroslavyaroslav @janndriessen Please be aware that the examples above are now the style for multiline function calls and guard multiline statements.
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.
@cclauss Thanks for the suggestion, I should've done that right from the beginning. |
@JeneaVranceanu Not sure is it my fault, but the pr is broken so far, fix it please. |
@yaroslavyaroslav Fixed. |
@@ -6,6 +6,7 @@ | |||
import Foundation | |||
import CryptoSwift | |||
|
|||
// swiftlint:disable cyclomatic_complexity |
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.
Shouldn't we enable it back at the end of the struct?
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.
No, not in this case.
Basically whole file requires refactoring, and for now to silence the cyclomatic_complexity issues in this file I've added that comment.
The rule is automatically re-enabled when SwiftLint leaves this file and starts linting the other one.
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.
There's a several questions to those changes.
Does this PR need a rebase? |
@cclauss It's merged with develop branch. |
Agreed. The whitespace-only changes like |
@cclauss just wonder how much your into us? If you are, I can add you to a list of reviewers that would make your review countable in ci/cd checks and grant you rights to merge, should I? |
case .Microether: | ||
return 12 | ||
case .Finney: | ||
return 15 |
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.
🌟
…anges chore: swift lint cleanup -- whitespace-only changes from #756
Summary of Changes
Review only after #761
Manually fixing SwiftLint issues.
Test Data or Screenshots
By submitting this pull request, you are confirming the following:
develop
branch.