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

Support automatic sorting by name pattern for sortDeclarations rule #1731

Merged

Conversation

oiuhr
Copy link
Contributor

@oiuhr oiuhr commented Jun 13, 2024

Changes referenced from previous pull request by @calda

@oiuhr oiuhr changed the base branch from main to develop June 13, 2024 23:21
Copy link

codecov bot commented Jun 13, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.21%. Comparing base (9a4258e) to head (cf24047).
Report is 1 commits behind head on develop.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #1731      +/-   ##
===========================================
- Coverage    95.24%   95.21%   -0.03%     
===========================================
  Files           20       20              
  Lines        23284    23323      +39     
===========================================
+ Hits         22176    22207      +31     
- Misses        1108     1116       +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Rules.md Outdated
Option | Description
--- | ---
`--sortedpatterns` | List of patterns to sort alphabetically without `:sort` mark.
`--sortedtypes` | default: `class,actor,struct,enum,protocol,extension`
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't really understand the purpose of the --sortedtypes option.

Reading the code, it looks like the set of --sortedpatterns values only trigger a type to be sorted if the declaration kind is also included in --sortedtypes. Is that right?

Is there a use case you have in mind for this? When would you want --sortedpatterns to not apply to all kinds of declarations?

Copy link
Contributor Author

@oiuhr oiuhr Jun 14, 2024

Choose a reason for hiding this comment

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

tbh I just needed a list of top-level declarations to sort. I've made an array of swiftTypeKeywordsto look at in parsing helpers and something clicked in me to making it into configurable parameter as in organizeDeclarations if I, for example, don't want to sort protocol declarations. I guess if it's not the case I can remove this parameter as redundant and just stick with swiftTypeKeywords, i don't have a strong opinion here

Copy link
Collaborator

Choose a reason for hiding this comment

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

Since we don't have a concrete use case in mind for this, to keep things simple I think it would be better to remove the --sortedtypes options and just refer to the hardcoded list of swiftTypeKeywords that you added.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done, thanks for your comments!

@@ -4123,6 +4123,48 @@ class OrganizationTests: RulesTests {
exclude: ["blankLinesAtEndOfScope"])
}

func testSortDeclarationsSortsByNamePattern() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks for following up on this!

@janviaroraa

This comment was marked as off-topic.

Copy link
Collaborator

@calda calda left a comment

Choose a reason for hiding this comment

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

Thanks!

@calda calda merged commit 931a02a into nicklockwood:develop Jun 18, 2024
7 of 9 checks passed
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.

None yet

3 participants