There are a lot of advantages of a good coding style. It helps to understand the project structure better, improves code readability, makes maintenance easier and speeds up onboarding for new team members.
Sure, every employee needs to have some freedom when writing code, but you do need to follow some standards still. If you are the only developer in a company, then sure, you can have even more freedom, you can basically write that app as you’d like and no one will be there to check your merge requests and leave you tons of comments😆.
But usually, if you work in a bigger company with more developers and all the code is going through merge requests, then that company will kind of impose a ‘coding style’ for all employees, so then at least everybody is on the same page.
We’re going to discuss 3 topics in this blog post, and those are:
- Swift Coding Style
- Coordinators vs Flow Controllers
1.Swift Coding Style and Standards
There are a couple of coding styles out there already, so we don’t need to reinvent the wheel.
I think the Ray Wenderlich one is the most simple and on point resource for this. This is the coding style we are using in the company I work for as well, so maybe that’s why I like it more :D. But seriously, a lot of coding styles out there tend to overly explain things in more complicated examples. The Ray Wenderlich one is very simple and it’s covering the most important and key things you need to know. He is writing about:
- Preferred ways of writing delegate methods
- Using mark for all your extensions
- Not using Type Inferred Context
- Add always spacing, to keep the code more readable
- Using self only when required by the compiler
- Using trailing closure syntax only if there’s a single closure expression parameter at the end of the argument list.
- Memory Management
- Lazy Initialization
- Syntactic Sugar
Also another good resource! But here you can find other subjects presented as well, like Rx, VIPER architecture, project flow and networking. For the coding style though it’s approaching the next subjects:
- Tabs, not spaces 😀
- Make liberal use of vertical whitespace to divide the code into logical parts
- Don’t leave trailing whitespace
- Closure expressions
- Avoid using force unwrapping of Optionals
- Make classes final by default
This is the most complex one and their examples are a bit more elaborated. You need to have some patience to finish it I must say, but it’s still a good resource to go through, even if you do it fast.
I think they cover pretty much all subjects here, but as an addition to what others have, are the following topics:
- Switch statements
- Static and class properties
- Error types
- Force unwrapping and force casts
- guards for early exits
2.Coordinators vs FlowControllers
The Coordinator pattern provides an encapsulation of the navigation logic. In other words : Instead of pushing and presenting your ViewControllers from other view controllers. All the screens navigation will be managed by coordinators. In this way, the view controllers will be isolated and invisible to each other, and could be reused easily.
The FlowController on the other way, is a simple object that will manage part of your app.
Three main roles of FlowControllers are:
- Configuring view controller for specific context
- Listening to important events on each ViewController and using that to coordinate the flow between them
- Providing the view controller with objects it needs to fulfill it’s role, in this way it’s removing any need for singletons in view controllers
- If you need to support multiple devices and different presentation modes, you have other FlowController class, no spaghetti code
Here you can find a nice example about this topic.
If you didn’t use SwiftLint in your projects until now, you are really missing out! SwiftLint is the most widely used Swift code analyzer which can be configured based on custom rules. It really helps you be consistent within your project, by enforcing a style, and it’s giving you warnings for things like:
- Trailing spaces
- Force unwrapping
- Function complexity
- Length of functions and classes
- Naming conventions
Of course, you are in charge of the configuration, so you can make adjustments to the rules. Here you can find more info about SwiftLint.
Instructions on how to install SwiftLint here.
All the resources mentioned helped me along the way to keep the code organized and better structured. Make a habit of using these tools and coding styles, and you will see a true difference. Plus, you will be appreciated by any company! Everybody loves a nicely structured code!