-
Notifications
You must be signed in to change notification settings - Fork 320
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
Clarify Rule: Use Swift's automatic enum values unless they map to an external source. #215
Conversation
… external source.
/// These are written to a logging service. Explicit values ensure they're consistent across binaries. | ||
// swiftformat:disable redundantRawValues |
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 should keep this example linter directive, since otherwise the linter would remove the redundant raw values
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.
@calda Thank you for your explanation! I learned something new today! I have fixed accordingly. Please review again. 😄
… external source.
enum UserType: String { | ||
case owner = "owner" | ||
case manager = "manager" | ||
case member = "member" | ||
} | ||
// swiftformat:enable redundantRawValues |
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.
The way this directive works is that you:
- disable the rule with
swiftformat:disable redundantRawValues
, so that SwiftFormat doesn't try to modify the enum - write the enum declaration
- re-enable the rule with
swiftformat:enable redundantRawValues
So each enum needs both the disable
and then enable
directive. We'll want to keep this one here, and then add the correct swiftformat:disable redundantRawValues
and then swiftformat:enable redundantRawValues
to the enum Planet: Int
declaration below.
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.
@calda Now, I totally understand why swiftformat:disable redundantRawValues
and swiftformat:enable redundantRawValues
were there. Thank you so much for your explanation. I truly appreciate your time and effort.
README.md
Outdated
|
||
// RIGHT | ||
// swiftformat:enable redundantRawValues |
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 should be:
// swiftformat:enable redundantRawValues | |
// swiftformat:disable redundantRawValues |
with the corresponding // swiftformat:enable redundantRawValues
directive after the closing }
of the enum
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.
Thanks for adding this here though!
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.
@calda I have implemented swiftformat:disable redundantRawValues
and swiftformat:enable redundantRawValues
to enum Planet: Int
like you mentioned. Once again, thank you for taking your time to explain everything. I really appreciate you.
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.
@calda By the way, should enum: ErrorType: String
and enum: ErrorCode
need to be implemented too?
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, since those enums don't have any "redundant" raw values (e.g. case error = "error"
would be "redundant" since the compiler generates that automatically)
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.
@calda Sorry to bother you again, but I am confused with "redundant" raw values and usage of swiftformat.
As I have read rules.md of swiftformat and your comment for serveral times, I think
enum ErrorType: String
in WRONG is the one that needs to be implemented withswiftformat:disable redundantRawValues
andswiftformat:enable redundantRawValues
as it needs to be excepted from swiftformat rules.enum Planet: Int
needs to be reverted as before, because it is straightly following Swift's automatic enum values, and it does not contain any redundant raw values.
May I hear back what you think on these two?
Thank you for your time in advance.
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.
Oops! Sorry, you're right -- my mistake. Mind making another PR to fix that?
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.
Thank you for getting back to me! I am on it. Allow me few seconds please! :)
… external source.
… external source.
Summary
This PR proposes to clarify comment of the "Use Swift's automatic enum values unless they map to an external source."
Reasoning
Please react with 👍/👎 if you agree or disagree with this proposal.