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

Auto-format with swift-format #150

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

DePasqualeOrg
Copy link
Contributor

I copied the swift-format and pre-commit configs that were recently added to Jinja. I also added a GitHub action to check formatting. This should minimize distracting diffs due to formatting. Feel free to change the formatting rules if you have a strong preference about them.

For future PRs, formatting can be applied with pre-commit run --all-files before committing.

@DePasqualeOrg DePasqualeOrg mentioned this pull request Jan 1, 2025
Copy link
Member

@pcuenca pcuenca left a comment

Choose a reason for hiding this comment

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

Thanks a lot for proposing this @DePasqualeOrg! However, I'd prefer to make style rules super minimal at this stage of the project. Can we work on something simpler, like what mlx-swift does?

.swift-format Outdated
Comment on lines 6 to 9
"lineLength": 120,
"maximumBlankLines": 1,
"respectsExistingLineBreaks": true,
"lineBreakBeforeEachArgument": true,
"multiElementCollectionTrailingCommas": true,
"spacesAroundRangeFormationOperators": true,
"rules": {
"AlwaysUseLowerCamelCase": false
}
Copy link
Member

Choose a reason for hiding this comment

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

Not a fun of imposing too many rules given the experimental nature of this project. Something like what's used in mlx-swift is enough in my opinion, and it solves most of the distracting differences I've seen in the project so far.

Copy link
Contributor Author

@DePasqualeOrg DePasqualeOrg Jan 3, 2025

Choose a reason for hiding this comment

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

I've changed the rules to mirror those used in mlx-swift. This applies a default line length of 100, which in my opinion makes the code look less nice. Not setting lineBreakBeforeEachArgument and multiElementCollectionTrailingCommas could result in more distracting diffs.

Copy link
Member

Choose a reason for hiding this comment

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

Ok, in that case let's use 120 for the line length, as you initially suggested, and multiElementCollectionTrailingCommas if you feel strongly about it. But I'd prefer to skip the lineBreakBeforeEachArgument for now, I find multi-lines more distracting than helpful when you are browsing the code.

Copy link
Member

Choose a reason for hiding this comment

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

I'd remove this file too to make it clear that git hooks are completely optional. Having a CI action to verify style is enough in my opinion. Contributors that want to auto-apply rules are still free to do so.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I included it because it's included in mlx-swift and mlx-swift-examples, and pre-commit hooks are not required there either. It just makes it simple to run the formatting with pre-commit run --all-files instead of having to remember the swift-format command. It would also unify the workflow for contributors to all these packages, so that we just have to remember one command.

Copy link
Member

Choose a reason for hiding this comment

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

All right, let's keep it then, I see it being useful for documentation and consistency.

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 coming up with this workflow! However, our CI configuration is a bit special for security reasons, we need to add workflows to this repo. We can work on a separate PR there!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@DePasqualeOrg
Copy link
Contributor Author

Done, thank you!

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