Code style at FARFETCH going beyond fashion
By having code guidelines and ways to enforce code style rules, we’re able to achieve a better codebase.
A good code style enhances the way we read code and improves visibility and organisation. When contributing to a large codebase as we have here at FARFETCH, following code guidelines and style rules is naturally beneficial to the code itself and the developers who constantly write and read it.
Robert C. Martin once wrote:
"Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes writing easier.”
Each person, throughout their journey, develops their own code style, a way to write code and format it as pleased. Although, if everyone just wrote code as they are used to, it could become very troublesome and somewhat confusing to read through such different possible styles. While if everyone in the team is aligned with a predefined standard, the overall code base improves as a whole and we’re also able to achieve better scalability and better understanding as well. We become comfortable with the style, and allows for greater understanding and assimilation for all, regardless of whether they are contributing by writing and reading code or reviewing merge requests.
At FARFETCH, we really value our codebase, and because of this, we have rules defined for code styling. It is important in our mobile domain to have every developer aligned with our code format, rules and conventions. As developers, we read and write code on a daily basis, so it is of great benefit to have a tool that helps us enforce and align a single code style for all.SwiftLint is used to accomplish just that.
SwiftLint is a tool developed by Realm, which allows the enforcing of specific and custom coding style rules. As we can see below, for each existing rule that is being broken, SwiftLint displays the problem highlighted in yellow, when it is a warning, and in red when it is an error. The tooltip appears next to the code line it occurred and with a small description to help fix it:
Warning example:
SwiftLint rule on the yml file:
Some rules are core and already exist as part of SwiftLint but we can also add our own custom rules. To do that, we simply need to add them to the swift.yml file, setting them up as if they are warnings or errors. While warnings can be ignored to a certain point, errors do not allow the code to compile successfully. When SwiftLint runs it will analyse the code for potential errors, using regex rules defined for each configuration in a process better known as linting. When the linting finishes, all the matching regex will be translated into highlights, either warnings or errors, with a specific tooltip. It is a highly configurable tool. For more information take a peek at SwiftLint GitHub.
SwiftLint really helps us maintain a healthy codebase here at FARFETCH, we currently have a no warnings policy, meaning each block of code introduced to the code base will only be accepted if the rules are met. Obviously, not all rules can be mapped to SwiftLint, other specific rules also exist and we have them documented. We can call these soft rules, and they are usually enforced on merge request reviews. Also, and since we work in a continuous integration environment, our pipelines run scripts for specific actions, where one of them is an integration using Danger, so any warnings existing in the code will be automatically flagged and reported as a comment on the merge request itself.
The way we coordinate the refreshing of these SwiftLint rules is through a recurrent meeting with all engineers where we can discuss changes to our guidelines, but the general rule would be the simpler, the better, as well as one rule to rule them all. Fewer variations or exceptions on specific rules help to keep ambiguity low. These meetings occur once every month, we call them Kumbayas, and every iOS developer is invited so that we can all discuss topics like new features, code guidelines, and whatever anyone wants to share with the rest of the team. It’s a great time for us to share knowledge, strengthen our culture, ask for advice on future developments, showcase possible improvements or discuss any kind of refactors. Also, any new updates Apple releases, such as iOS versions and Swift language updates, are also shared and discussed here.
All of this combined translates into a code that is written by more than 60 developers, but it feels very familiar to anyone who reads it in our domain, making it easier to understand, refactor or add and delete code as needed.
Code is much more than business rules translated into a language that computers can read, and as stated by Martin Fowler:
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”.
Definitely one of the ways to achieve such understandability is by standardising the code style, and we invite you to do the same in your projects.
