Skip to content

style: Apply SwiftFormat and add code quality toolkit script #106

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

dioKaratzas
Copy link

  • Auto-format Swift codebase using SwiftFormat to enforce consistent spacing and indentation
  • Fix trailing commas, self usage, and import ordering
  • Add script_hub.sh as a unified code quality toolkit that: • Automatically detects and installs SwiftFormat/SwiftLint via Homebrew • Provides interactive menu for running formatting/linting tools • Shows color-coded output with detailed error reporting • Streamlines the development workflow with consistent code style

- Auto-format Swift codebase using SwiftFormat to enforce consistent spacing and indentation
- Fix trailing commas, self usage, and import ordering
- Add script_hub.sh as a unified code quality toolkit that:
  • Automatically detects and installs SwiftFormat/SwiftLint via Homebrew
  • Provides interactive menu for running formatting/linting tools
  • Shows color-coded output with detailed error reporting
  • Streamlines the development workflow with consistent code style
@dimitris-c
Copy link
Owner

Thanks for the PR.
I wouldn't add the script, since it doesn't add much value, ideally swiftformat / swiftlint should be run as part of Xcode's build phase to ensure correct format before a release is made.

@dioKaratzas
Copy link
Author

dioKaratzas commented May 15, 2025

Hey @dimitris-c , thanks for the review!

I’m totally on board with running SwiftFormat/SwiftLint in the Xcode build phase. Besides the build-phase checks, we can also add a GitHub Actions step that lint-checks every PR.

The small script_hub.sh wrapper is just there to lower the barrier for casual contributors:

  • One-liner setup: ./script_hub.sh format installs (via Homebrew, if needed) and runs the formatter/linter in a single command.
  • Editor-agnostic: Not everyone opens the package from .xcproject or even Xcode—some use VS Code or work from Linux—so having a CLI entry point keeps the workflow consistent.
  • Pre-push safety net: Contributors can format everything locally and be confident the CI will pass before pushing.

Happy to move or rename the script if it feels out of place—the goal is simply to make it easier to keep the codebase consistently formatted while still enforcing the rules in CI.

Let me know what you think! 🙌

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