All Ruby on Rails Node JS Android iOS React Native Frontend

Keeping your code clean

Keeping your code clean - this is something that doesn’t always go hand in hand with programming, especially in a larger team where people can have different experience and code style preferences. You can think "clean code - is it that important?". Believe me, it is.

The scenario is usually simple - there is a very important feature to implement, but there is also a very short deadline for it. Probably every programmer had such situation in his career. Often, it ends on getting the job done with an intent of writing code that works but sometimes it’s not that beautiful as you would want. You are only incurring the debt to yourself because you'll probably have to go back to this code again. Now imagine that you’re coming back after a long time…

 

  

This post will show you a few quick tips for a cleaner code and tools that can help maintain the same code style and avoid errors that can/will lead to less readable code.

LOC

You've probably heard that abbreviation multiple times in many articles and it's not new for you. This is repeated very frequently, but many programmers are simply forgetting about it. It is also something that novice programmers do not pay much attention to. LOC means lines of code and it’s one of the software metrics used to measure the size of a program. The fewer lines of code the easier it gets to read it. I think it is not a strange statement. 

The main mistake is creating functions that have more than one task. If a function is too long, it is a sign that it probably has more than one task. Reading it can also cause a lot of problems. This of course also applies to the size of files - it is better not to overdo it.

Solution? Split functions into smaller and make sure that they’re not doing too much.

Correct Indentation 

 

It seems that this is not so important - one space more or less, what's the difference? However, this is the first thing that stands out most. In fact, this is a very important issue that strongly affects the readability of our code. Consider the following code that does not have any indentation:


extension Sequence where Element: Hashable {
func containsDuplicates() -> Bool {
var set = Set()
for element in self {
if !set.insert(element).inserted {
return true
}
}
return false
}
}

 

Doesn't it look terrible? Of course it does, this is quite an extreme case which you probably will never see, so let's look at another snippet that has indents, but in some places they are missing:


extension Sequence where Element: Hashable {
    func containsDuplicates() -> Bool {
        var set = Set()
        for element in self {
        if !set.insert(element).inserted {
            return true
        }
        }
        return false
    }
}

 

It is not as tragic as before, but it’s still not perfect. Let's see a perfect version then.


extension Sequence where Element: Hashable {
    func containsDuplicates() -> Bool {
        var set = Set()
        for element in self {
            if !set.insert(element).inserted {
                return true
            }
        }
        return false
    }
}

 

Do you see a difference? It's really important, so pay attention to your indentation habits!

Naming Standards

Another very important thing. Most of the projects are developed by teams consisting of more developers than just one and this means that the code should be readable for everyone. When you create a variable or a function you should give it a full name which will be descriptive enough to give a general idea of what it is for or what it does. Never use only one letter in the name. It is better to spend more time on the appropriate naming than on future redesigns.

 

Let’s consider the following simple function: 


extension Date {
    func add(_ v: Int) -> Date? {
        var components = DateComponents()
        components.day = v
        return Calendar.current.date(byAdding: components, to: self)
    }
}

 

This code is not readable at all and other developers definitely will not understand what this method does. Of course, you can add documentation to the code, but it's still not a good way out - the code itself should be readable. Let's try to make some refactoring.

 


extension Date {
    func addDays(_ value: Int) -> Date? {
        var dateComponents = DateComponents()
        dateComponents.day = value
        return Calendar.current.date(byAdding: dateComponents, to: self)
    }
}

 

Isn't it much better now?

Variables/Methods Declaration

All variables and methods should be grouped according to the access level - methods and public variables should be above those marked private/the private ones. All variables in the class should be declared at the top of the class. Making it this way will save you time scrolling over the whole class to find where it was declared.

Methods should be also declared in the same order as they are used - method A which calls method B shouldn't be below.

Code Style

Last thing and surely the hardest one - code style. Many developers have their own code style based on the previous experience and it can not be clearly stated that a given style is the best and everyone should write in this way. 

 

One way to develop is to participate in open source projects, as well as to check the code of other programmers. The function you are working on at the moment has probably been implemented more than once. Of course, we are not talking about copying and pasting a ready solution, but about analyzing it and drawing conclusions. Maybe the solution has some drawbacks? Maybe you can offer something different? You can really learn a lot this way. It is also worth to check some Swift style guides - for example, from LinkedIn and Ray Wenderlich.

But what if you are taking care only of the clean code in your project? What if there are several programming styles in it? What to do to make the project consistent? How to force the same style around the team? A lot of questions, but fortunately there is a solution. The linting tools come with help 

Linting Tools  

 

I will not bore you with a typical definition of "lint" that you can read on Wikipedia, so I will explain briefly - these are the tools that check your code in terms of programmatic and stylistic errors. They are very helpful in identifying common mistakes but also in keeping consistent code style. And now I will show you some linting tools that you can use in iOS projects.

SonarQube

SonarQube is an open-source web-based platform for continuous inspection of code quality that can be extended with open source plugins. It supports more than 20 languages like Java, C/C++, Objective-C, C#, Swift, and many others.

Sonar has a few metrics which are covering a generous area of code quality:

  • Reliability - Number of bugs
  • Security - Number of vulnerabilities
  • Maintainability - Number of code smells
  • Coverage - Number of lines covered by the tests
  • Duplications - Number of duplicated blocks of lines
  • Size - Number of all files, classes, functions, and statements
  • Complexity - It is the complexity calculated based on the number of paths through the code

 

 

Sonar at this moment has 116 rules for Swift, which are divided into four groups:

  • Vulnerability - 4 rules
  • Bug - 14 rules
  • Security Hotspot - 1 rule
  • Code Smell - 98 rules 

They can be also marked in the aspect of severity as:

 

 

SonarQube can be integrated with continuous integration systems, however, free version supports only a few languages and can be used with public repositories only. It has a web dashboard which can be easily shared and can be really helpful in a situation when you work on a legacy code. You can use Sonar with a local or remote server and configure it by adding sonar-project.properties file beside the .xcodeproj file, in your Xcode project root folder. If you want to disable some rules, you’ll need to use a web dashboard and deactivate it there.

 

Conclusion

It’s a really great tool, however, it requires a running server and we can’t integrate it with Xcode to see all errors during the implementation process. Free version supports only open-source projects.

Tailor

Tailor is an open-source cross-platform static analysis and linting tool for Swift. You can use this tool on macOS, Linux, and Windows. It analyzes your code to ensure Swift style and conventions. It has available 30 rules and is using primary Java target of ANTLR. At this moment it has 1244 stars on the Github and the last commit was on 6 December 2017.

 

 

Unlike SonarQube, you don’t need any server to run this tool. You can also integrate it with Xcode to get Tailor’s output within Xcode Editor Area and in the Log Navigator. Installation is done by Homebrew. You can also generate a report in the specific type like HTML or JSON. 

Configuration is done by adding a file .tailor.yml in the project root folder. You can include or exclude certain files and directories from the analysis, enable and disable specific rules, specify output format or color scheme for CLI.

 

Conclusion

Using a tool without any server and also the possibility to integrate it with Xcode is a cool thing. It’s also very simple to customize by using a configuration file which can be placed in a repository. Making it this way all developers in the project will be using the same configuration. The only downside is the small number of rules.

SwiftLint

This is probably the most well-known tool. It’s an open source project developed by the Realm team which you’ve probably already heard of. Right now it has more than 10,000 stars and 1,000 forks on the GitHub. SwiftLint has 150 rules and it’s being constantly maintained.

  

 

Like Tailor, you can install this tool by using Homebrew and also by CocoaPods. Integration with Xcode is also possible. Configuration is also similar - you need to create a .swiftlint.yml file in the project root folder. You can disable or enable optional rules, add paths which should be included and excluded during linting and also you can configure some rules. 

There are a lot of rules but if you run out of something, you can define your own in the configuration file. SwiftLint can also automatically correct certain violations and generate a report in different types.

  

 

Conclusion

A really great tool which is maintained since April 2015. Probably the most famous linting tool in Swift community. You can integrate it with Xcode and your continuous integration tool by using Homebrew or dependency manager. There are a lot of rules and the possibility to create your own.

 

Why should we use this tools?

During implementation of the application we have a lot on our minds and we're not perfect - we make mistakes. But, since there are tools that can prevent us from these mistakes, why not use them? It’s also good to have established style in the project across the development team. It’s very useful to have consistent codebase, especially when you work in a big iOS team.

 

Why also not to have your own established rules? Here at Netguru we have our set of them that should be used in the project. Thanks to this, the projects in which this tool was applied will be consistent and there will be no problems when the new developer joins the project. Every single build will correct your tiny mistakes and will inform you about all violations. Don’t be afraid and use it from the start of your project, and if it is already in progress, think about implementing it. Trust me, you will not regret it.

We're building our future. Let's do this right - join us
New Call-to-action
READ ALSO FROM iOS
Read also
Need a successful project?
Estimate project or contact us