-
Notifications
You must be signed in to change notification settings - Fork 58
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
Use SwiftLint via CocoaPods #78
Conversation
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.
Basically almost same remarks/questions as in SwiftGen/SwiftGen#401 😉
- type_name | ||
|
||
opt_in_rules: | ||
- force_unwrapping |
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.
👍, + 💯
XCTAssertTrue(try Filters.parseBool(from: ["true"])!) | ||
XCTAssertTrue(try Filters.parseBool(from: ["yes"])!) | ||
XCTAssertTrue(try Filters.parseBool(from: ["1"])!) | ||
// swiftlint:enable force_unwrapping |
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.
Maybe we should instead use XCTAssertTrue((try …) ?? false)
or XCTAssertEquals(try …, true)
to avoid the force-unwrap here? Especially, in case there's a regression one day and the test parseBool(from: ["true"])
starts to fail and return an unexpected nil
, that force-unwrap will make the test harness crash and stop the whole test process, instead of marking that test as failed and continue with other test cases…
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.
We'd have to be careful then to provide the "inverse" value as a fallback for each test. Here it's true, for the parseBool(from: ["false"])
it should be false, ...
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.
Yeah that's why I'd prefer to use the more readable XCTAssertEquals(…, true)
there rather than XCTAssertTrue(… ?? false)
@@ -4,7 +4,6 @@ machine: | |||
|
|||
dependencies: | |||
post: | |||
- bundle exec rake lint:install |
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.
Same questions as in SwiftGen/SwiftGen#401 (comment)
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.
Same answer
rakelib/lint.rake
Outdated
task :code do |task| | ||
Utils.print_header 'Linting the code' | ||
config = Pathname.getwd + '.swiftlint.yml' | ||
Utils.run(%(#{SWIFTLINT} lint --strict --path Sources --config "#{config}"), task) |
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.
Same q as in SwiftGen/SwiftGen#401 (comment)
4879ab3
to
86ef8e2
Compare
Scripts/SwiftLint.sh
Outdated
#!/bin/bash | ||
|
||
SWIFTLINT="$(PWD)/Pods/SwiftLint/swiftlint" | ||
CONFIG="$(PWD)/.swiftlint.yml" |
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.
Same as SwiftGen/SwiftGen#401 (comment)
ce85ba3
to
831d1a0
Compare
Same as SwiftGen/SwiftGen#401