To err is human. While developers try to write clean codes, it is natural to make some minor mistakes or errors along the way owing to tight deadlines, large teams, and the complexity of the task. That is exactly where iOS code review comes in handy.
The code review process is a healthy software product development practice that reduces the possibility of defective software and additionally, avoids business failures and losses.
There are some best practices that could be followed during code review for iOS app development that helps to ensure code quality, security and performance, codebase stability and scalability, and software security.
This blog list tips to enhance the iOS app code review process and also makes the exercise more effective and fruitful for a business.
Lint is a static code analysis tool that lays down a set of coding rules and also checks if the code follows them. Any deviation is detected and reflected during a code review.
Every language has its own lint or linter, for example, Swift Lint, Java Linter, ESLint, etc. Using Lint as a code defect detector helps developers to maintain code quality and enhance overall application performance.
2. Use SonarQube for enhanced security
An open-source platform that detects bugs and code smells, SonarQube is an extremely helpful code review tool. Along with code quality, this tool mainly checks for security hotspots and detects potential vulnerabilities in your code and also reports code duplicity.
A failure to write the code in accordance with necessary standards, SonarQube helps developers track resultant code smells and in addition, fix the technical debt. Supporting 17 languages, this code review tool detects and reports security flaws and breaches such as SQL injection, cross-site scripting (XSS), and insecure random numbers within seconds and enhance code security.
Solid design principles are a set of combined principles. These principles provide developers with the guidance to make software designs comprehensible, easily maintained, and additionally, conveniently extended or scaled.
Reviewers should make sure these principles are followed in programming as software code written keeping them in mind are:
more conveniently shared with the collaborators,
scaled up to match the volume,
modified as per user needs,
tested for stress or usability and,
managed and troubleshot without any issues
Furthermore, a code should be reviewed for the use of the single source of truth principle. For example, a developer should not preserve the same information in multiple places in the code.
S.O.L.I.D is a set of following principles:
1. Single responsibility principle:
Every module designed should solely carry out its responsibility over a single part of the functionality provided by the software.
2. Open-closed principle:
Availability and also easy extendibility of any part of the software to add additional features, without modification.
3. Liskov substitution principle:
The accuracy of a particular program should be maintained while replacing an object within the program with instances of their sub-category types.
4. Interface segregation principle:
Do not add new functionalities or methods to an existing interface. Instead, it is suggested to incorporate a new interface and then give permissions to classes to implement different interfaces as and when required.
5. Dependency inversion principle:
A design pattern known as a dependency inversion pattern, usually resolved using dependency injection, should always be used.
4. Check if Apple guidelines are followed
While writing codes for iOS applications and conducting code reviews, it is extremely important to follow and check a codebase for Apple guidelines.
Apple provides developers with a set of design and coding guidelines to be followed while developing iOS applications. These guidelines are secure, perform as per Apple standards, and additionally, could be hosted on the App Store hassle-free.
Apple strongly recommends the usage of MVVM (Model View View-Model) architecture, especially for the UIKit development of an iOS application.
A code reviewer should specifically ensure that Apple guidelines and rules are adhered to.
5. Check code complexity
Code should be clean for a well-functioning and scalable iOS application and hence should be strictly reviewed during a code review process.
We judge optimal solutions based upon time and space complexity. The former refers to execution and launch time, while the latter points out variable and data collection that makes a codebase heavy and difficult to maintain and scale.
Both these components should have less Big O asymptotic Notation in order to ensure milestone deliveries and codebase health.
Note: Big O(O) is used to detect best cases of a code complexity.
6. Review naming conventions
Naming should be clear and consistent and hence variable, functions and class naming conventions, in particular, should be thoroughly reviewed. It should be checked that variables are written using camel case writing styles whereas class names are written using sentence case writing style.
Furthermore, variables should be correctly declared in the codebase, relating to the purpose they serve.
1. Boolean values should start with is, can, should, and will.
2. When in doubt – use longer names over shorter names to bring more clarity.
3. Magic numbers should be avoided. Instead, constants should be added in codebase memory using Struct in order to reduce space complexity.
7. Remove commented code
During a code review process, check for commented code. If the same exists, remove it. Commented codes lead to code smells.
Moreover, a developer can use Git commit for a particular variable change or for future purposes, however, commented code should never be added to a codebase.
8. Localized strings
A code reviewer should check for hard-coded strings. Hardcoded strings take up a lot of space and redundancy of changing a particular value of a variable, thus demanding more time and effort.
Instead, localized strings should be used for string values. A localized string gets initialized at one place in RAM and could be called easily. This enables a developer to make changes at a single place that would get reflected everywhere else in the application.
Therefore, a code review process should ensure that all strings are localized and if there doesn’t arise a need to localize a string in an application, constants should be used instead.
9. Ensure code documentation
It should be checked during a code review that code is documented in order to maintain coding standards across all development teams. It helps multiple developers working on a single project by bringing in more clarity of methods, the features implemented through them, their relevance, and usage.
10. Enable code log
As we can track changes in an Excel sheet or Google docs, similarly we can track code execution and method responses by enabling a code log. Errors in APIs or any changes are reflected in this log which helps a developer keep track of the code progress.
A code review checklist for iOS apps helps engineers maintain code quality, and codebase health, meet requirements, and follow guidelines effectively.
Hope these 10 tips given above would help developers to build iOS applications with more ease, precision, and clarity, saving time, effort, and most importantly, costs.
Q1. What are some best practices for iOS code review?
Some best practices for iOS code review involve checking for lint warnings, naming conventions, localized strings, commented code, etc. Furthermore, ensure that code documentation has been done and log is enabled. Also, look for the application of S.O.L.I.D principles and ensure that Apple guidelines are followed in programming.
Q2. What tools can be used for iOS code review?
SonarQube, GitHub, Review Board, CodeScene, etc., are some of the tools that can be used for iOS code review.
Q3. How does code review benefit iOS developers?
Code review helps iOS developers to maintain code quality, and performance and avoid bugs, security flaws, errors, and code smells.
Q4. What are some common mistakes to look for in an iOS code review?
Common mistakes to look for in an iOS code review: 1. Look for proper null check of optional values in Swift code, 2. Check for force unwrap of optional values, 3. Look for inappropriate use of dispatch queue 4. Ensure that closure has weak self in capture list 5. Check if weak keyword should be used for any delegation method
Q5. How can code review improve the quality and efficiency of iOS app development?
The process of code review ensures that the code is clean and as per quality standards. A robust, stable and scalable code ensures that the software doesn’t fail due to bugs and security breaches or flaws, is capable of versioning with updates, doesn’t crash with high user demand, and new features and functionalities could be added as required.