Introducing LinkedIn’s Official Swift Style Guide

June 22, 2016

Swift at LinkedIn

Code review is one of the most fundamental aspects of a successful software engineering team. Some of the goals of code review include ensuring correct functionality and best practices, providing a forum for positive and constructive feedback, creating broader exposure of the codebase for developers, and ensuring code readability and consistency. By ensuring the quality of the code, we can significantly decrease the cost of code maintenance and developer onboarding, which results in fewer bugs, more easily reusable code, and an overall better product. However, as a team grows in size and forms specialized subteams, it becomes more difficult to ensure consistent best practices, styling, and readability across all units.

This is why we introduced the concept of a “platform code review” into our development process for building the new LinkedIn mobile apps. Under this system, every code change needs to be reviewed by at least two people: a product reviewer and a platform reviewer. The product reviewer is an expert in the product area—usually a member of the same team as the code’s author—that can make sure the changes to the code make sense. A platform reviewer is an expert for a platform (e.g., iOS, Android, Web) and language (e.g., Swift, Java, JavaScript). The platform reviewer’s job is to make sure that reviewed code is consistent with the rest of the codebase, easy to read, and adherent to the best practices defined for the platform. We have separate platform reviewer groups for iOS, Android, Web, and our back-end infrastructure.

Enforcing a consistent coding style is an important part of code reviews, but it can be difficult to get large teams to agree on a single, unified style if one doesn’t already exist. We often have multiple teams writing Swift code, and each team may evolve its own style, so we needed to converge toward a single style across the company. After creating an initial document based on existing style guides we had for various teams, the iOS platform reviewers discussed which practices should be universally adopted.

For some decisions, we ended up taking a vote, because some aspects of code styling depend purely on personal preferences. Other decisions were clearer though, for instance when a certain practice or styling had been set as precedent by Apple, helped prevent common errors, etc. Thanks to the effort of many reviewers, we now have an official Swift Style Guide for LinkedIn that is updated for Swift 2.2. You can go check it out now on GitHub!