Skip to content
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

Merged

Conversation

JeneaVranceanu
Copy link
Collaborator

@JeneaVranceanu JeneaVranceanu commented Feb 2, 2023

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:
  • I have reviewed the Contribution Guidelines.
  • I have performed a self-review of my own code.
  • I have updated my repository to match the develop branch.
  • I have included test data or screenshots that prove my fix is effective or that my feature works.
  • I have checked that all tests work and swiftlint is not throwing any errors/warnings.

* 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
@JeneaVranceanu JeneaVranceanu mentioned this pull request Feb 2, 2023
4 tasks
.swiftlint.yml Outdated
- type_name
- identifier_name
- line_length
- multiple_closures_with_trailing_closure
- todo
- indentation_width
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Enabling this rule doesn't allow us to have multiline function calls like this one:

Screenshot 2023-02-03 at 15 00 29

Copy link
Contributor

@cclauss cclauss Feb 4, 2023

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.

Copy link
Collaborator Author

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:

Screenshot 2023-02-05 at 15 33 32

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:

Screenshot 2023-02-05 at 15 31 20

This variation is also allowed by the rule, but it's less readable and not pleasant to look at at all:

Screenshot 2023-02-05 at 15 36 13

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This rule is all about indentation and is compatible with almost all code in web3swift.
It doesn't force us to write guard statements in multiline always. Here is one of the acceptable examples:
Screenshot 2023-02-05 at 15 41 53

.swiftlint.yml Outdated Show resolved Hide resolved
.swiftlint.yml Outdated Show resolved Hide resolved
@JeneaVranceanu
Copy link
Collaborator Author

@cclauss Thanks for the suggestion, I should've done that right from the beginning.
Opened 2 new PRs with config file changes and with swiftlint --fix changes only.

@JeneaVranceanu JeneaVranceanu added the ready for review issue is resolved, a final review is needed before closing label Feb 5, 2023
@yaroslavyaroslav
Copy link
Collaborator

@JeneaVranceanu Not sure is it my fault, but the pr is broken so far, fix it please.

@JeneaVranceanu
Copy link
Collaborator Author

@yaroslavyaroslav Fixed.
But this has to be merged first -> #761

@@ -6,6 +6,7 @@
import Foundation
import CryptoSwift

// swiftlint:disable cyclomatic_complexity
Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator

@yaroslavyaroslav yaroslavyaroslav left a 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.

@cclauss
Copy link
Contributor

cclauss commented Feb 9, 2023

Does this PR need a rebase?

@JeneaVranceanu
Copy link
Collaborator Author

JeneaVranceanu commented Feb 9, 2023

Does this PR need a rebase?

@cclauss It's merged with develop branch.
There are still plenty of files that have changes but these are the result of things like replacement of {return nil} with { return nil }.

@cclauss
Copy link
Contributor

cclauss commented Feb 9, 2023

Agreed. The whitespace-only changes like{ return nil } could moved to a separate pr that is trivial to review and land. This would leave just those few modifications that require more debate or rewriting or linter directives.

@yaroslavyaroslav
Copy link
Collaborator

@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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🌟

cclauss added a commit to cclauss/web3swift that referenced this pull request Feb 10, 2023
JeneaVranceanu added a commit that referenced this pull request Feb 10, 2023
…anges

chore: swift lint cleanup -- whitespace-only changes from #756
@JeneaVranceanu
Copy link
Collaborator Author

@cclauss Thanks for the #773
This PR is updated now.

@JeneaVranceanu JeneaVranceanu merged commit bce743e into web3swift-team:develop Feb 10, 2023
@JeneaVranceanu JeneaVranceanu deleted the chore/swift-lint-cleanup branch February 10, 2023 12:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready for review issue is resolved, a final review is needed before closing refactoring
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants