Issue #1 - Highlights from 2020
Hi there. How awesome of you to stop by!
This issue was actually never sent to anyone. I've just created the newsletter, and this is a sample of how the future issues might look. I will share the valuable code improvement tips I stumble upon while browsing Twitter, spiced by occasional comments from my side. I cover Swift, Objective-C, UIKit, SwiftUI and much more. The plan is to send the newsletter every two weeks or once a month.
This issue contains my most favourite tips from 2020. Code improvement tips rarely age, so I hope you find these useful 🙌
Change suggestions in PR comments
While multiline change suggestions were introduced on Github all the way back in February 2020, it's such a time saver during code reviews, that it is worth reminding about.
When a you use change suggestions in PR comments, the changes can be incorporated automatically with a click of a button in the web UI, without having to first apply requested changes locally and then pushing to remote.
Tired of translatesAutoresizingMasksIntoConstraints?
This is the nicest way I’ve ever seen to deal with translatesAutoresizingMasksIntoConstraints.
let label = UILabel().forAutoLayout() // just like that 🤯 by @ZiadeMarcus
Access control for performance
It's not obvious that choices such as marking types and members private or final, or choosing between using struct or class are not only code style preferences, but also affect performance. Read the article by Avi Tsadok:
9 Ways to Boost Your Swift Code Performance | by Avi Tsadok | Better Programming
Swift is a fast language and it gets faster in every release. iOS devices are also fast, so the chances are these tips won’t be needed at all. Even in those cases where we do bump into performance…
Any documentation > no documentation
A reminder that even smallest bits of documentation can be helpful. via @SergDort
I love this idea of functions only taking the most specific parameters they need, courtesy of @Jonathanff. This approach doesn't only improve reusability, but also reduces unwanted side effects (possibility of changing something you didn't mean to change) and makes code easier to review. It's not a silver bullet though, so use with care.
Tech debt as a tool
Adding tech debt is acceptable in some cases, and is often necessary. @danielsaidi shares a solid approach to accepting technical debt:
To end on a fun note...
Nothing and no one is perfect, let's just remember that we're all human 😇
What did you think about these tips? I'd love to hear your thoughts on Twitter via @ios_code_review or over email at firstname.lastname@example.org 🙌