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

Clarify Rule: Use Swift's automatic enum values unless they map to an external source. #215

Merged
merged 4 commits into from
Mar 21, 2023

Conversation

teddy5518
Copy link
Contributor

@teddy5518 teddy5518 commented Mar 21, 2023

Summary

This PR proposes to clarify comment of the "Use Swift's automatic enum values unless they map to an external source."

Reasoning

  1. I indicated whether the examples are wrong or right like other rules in the guide to increase readability.
  2. The origin comment was not being specific as it only said "swiftformat:enable redundantRawValues" and "swiftformat:disable redundantRawValues". The heading of rule provides link to swiftformat, so I thought it was better to directly indicate that the examples are right for relying on Swift's automatic enum values.

Please react with 👍/👎 if you agree or disagree with this proposal.

/// These are written to a logging service. Explicit values ensure they're consistent across binaries.
// swiftformat:disable redundantRawValues
Copy link
Member

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

Copy link
Contributor Author

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. 😄

enum UserType: String {
case owner = "owner"
case manager = "manager"
case member = "member"
}
// swiftformat:enable redundantRawValues
Copy link
Member

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:

  1. disable the rule with swiftformat:disable redundantRawValues, so that SwiftFormat doesn't try to modify the enum
  2. write the enum declaration
  3. 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.

Copy link
Contributor Author

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 redundantRawValueswere there. Thank you so much for your explanation. I truly appreciate your time and effort.

README.md Outdated

// RIGHT
// swiftformat:enable redundantRawValues
Copy link
Member

Choose a reason for hiding this comment

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

This should be:

Suggested change
// swiftformat:enable redundantRawValues
// swiftformat:disable redundantRawValues

with the corresponding // swiftformat:enable redundantRawValues directive after the closing } of the enum

Copy link
Member

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!

Copy link
Contributor Author

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.

Copy link
Contributor Author

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?

Copy link
Member

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)

Copy link
Contributor Author

@teddy5518 teddy5518 Mar 21, 2023

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

  1. enum ErrorType: String in WRONG is the one that needs to be implemented with swiftformat:disable redundantRawValues and swiftformat:enable redundantRawValues as it needs to be excepted from swiftformat rules.
  2. 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.

Copy link
Member

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?

Copy link
Contributor Author

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! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants