Over the last few months, we have been working hard on our very own Swift style guide, based on our experiences writing Swift code. Now, we are proud to publish the result of this initiative: The Prolific Interactive Swift Style Guide.
When we started writing this guide, we knew the last thing we wanted was to generate a style guide in a void. How could we vet which Swift styles were good, and which were bad, if we didn’t have a good baseline for those decisions? As a result, we made sure to base our style guide off three important factors.
- All iOS engineers at Prolific take a code test during the interview process where they put together a small app. For transitioning to Swift, we required all iOS engineers to retake this same code test using only Swift this time and with no guidance of style or requirements. This was incredibly important in our development of the style guide. We found recurring questions and problems people were having in nearly every project, and we used those pain points as a skeleton for what should be addressed in our style guide.
- Next, we formed a small committee of project leads who were using Swift in production-level applications to debate the merits and validity of each point. We made sure to test and research each item in order to make sure we were making a decision that allowed us to write clean, consistent code.
- Finally, we used the community and the Swift development team for feedback on each point to make sure that we were making strong and valid choices. We also used the open-source Swift library as a resource to see what the Swift development team had to say on specific topics.
We stuck to a few important guiding principles when considering each rule that we added to the style guide:
- Was it useful? More broadly, did the rule actually allow us to write better, consistent code?
- Was it cumbersome? If a proposed rule ended up being cumbersome or frustrating to use, then it was immediately ruled out from being included. After all, the goal was to write cleaner code, not take more time to write it.
- Did it fit in with the Swift developer’s vision of the language? The open sourcing of Swift was an incredible resource for how we incorporated ideas into our ruleset. Reading through rejected proposals illustrated that Swift code is being developed to be clear, yet concise, and we made sure that our rules followed in that vein.
- Does it fit with the community? As Swift is now open source, it is truly a language that belongs to the developer community, so it was important for us to make sure that we fit in with the general community’s leanings.
There are certainly gaps in our style guide, but many of them are on purpose. In many cases, we did not have a clear understanding of what the implications of making a rule would be. In these instances we decided it would be better to omit the rule rather than commit to one that ultimately led to cascading problems down the line. There are other gaps we may have missed, and we welcome your help by contributing!
We have open-sourced our style guide in order to contribute to the community discussion on Swift style. But we also understand that our style guide is not perfect, and with the language constantly evolving, we need to keep evolving as well. As such, we encourage any and all developers to contribute to our style guide in any way they want. There are two ways you can join in the discussion:
- File an issue: If you have a more general concern or question that should be considered, but are not sure you can file a definitive rule on it, file an issue presenting that question to the group. We already have a few on GitHub that we are waiting to answer until we can rule definitively on it.
- Submit a pull request: If you think you have something great, file a pull request and we will add it! Make sure to consider the guiding principles above and consider what your pull request adds to the discussion of Swift style.
We’re very proud of the work we have put together and even more excited about the prospect of continuing to expand and revise our styles. There is still work to be done, but we believe we have compiled a very strong starting point for styles in Swift that we can use going forward.