Forem: Darlan Tódero ten Caten

Never rely on Strings for conditionals

Darlan Tódero ten Caten — Mon, 14 Dec 2020 01:53:31 +0000

Almost all the time is a bad decision to use Strings in conditionals because you will have no help from the compiler to alert you when you typed them wrong.

Throw the first stone the developer who never lost hours of work debugging because the code doesn't work until he finds out that he typed an incorrect String...

// a utility function somewhere
func isTheMain(route: String) -> Bool {
    return route == "Main"
}

// used somewhere else...
let route = "main"
if isTheMain(route: route) {
    ...
}

Can you spot the problem in the above code? Only the case of the string is different, enough to hide hard-to-find bugs. We can do better. We must write better code!

Sure, we can use constants to write the String just once and be safe using it. But I prefer to use enums because they add great flexibility to my code. Let's see it.

Enum to the rescue

This kind of special data structure is very useful for many needs, especially in Swift where it is very powerful when used with Switch conditionals, for example. More on that later.

First, let's fix the previous code using enum:

enum Routes: String {
    case Main
    case AnotherRoute
}
func isTheMain(route: Routes) -> Bool {
    return route == .Main
}

// used somewhere else...
let route: Routes = .Main
if isTheMain(route: route) {
    ...
}

We now have a source of truth for anything related to routing in the app and we can use this with confidence because we are no longer writing texts manually. Note that in Swift we can omit the Enum's name when using it, just type dot and the value. The compiler infers the type for us.

Also, if the String comes from an API or database, for example, we can easily create our route just by using the Enum initializer:

// we believe it comes from a reliable source
let routeStringFromDatabase = "Main"

let route = Routes.init(rawValue: routeStringFromDatabase)

In Swift, Enum works great with Switch conditionals

Another benefit of using Enum can be perceived when used in Switch conditionals because the compiler obligates us to define all the actions for every Enum option if we don't use the default case. Let's see:

enum Routes: String {
    case About
    case Home
}

func doSomethingWith(route: Routes) -> Void {
    switch route {
        case .About:
            print("Let's see the about page")
        case .Home:
            print("The boring home page")
    }
}

Note in this code above that we have two cases in the Routes enum and in the function we have a switch conditional that defines actions for every case (just a print in this example). We call it an exhaustive switch.

And the great thing about it is when you need to add another route and the compiler immediately throws errors at you because the switch is not exhaustive anymore:

There we have a compiler working for us to write more reliable code.

Look at your prepareForSegue methods

I bet you will find something to refactor in them because it is very common to open Swift projects and find code like this:

override func prepareForSegue(segue: UIStoryboardSegue!, sender: AnyObject!) {
    guard let identifier = segue.identifier else { return }

    if identifier == "About" {
        ...
    } else if identifier == "Home" {
        ...
    } else if identifier == "Login" {
        ...
    }
}

I know, the identifier String comes from the UIKit and we have to work with it. But you can easily change the if else conditionals to be more safe using our Routes enum:

override func prepareForSegue(segue: UIStoryboardSegue!, sender: AnyObject!) {
    guard let identifier = segue.identifier else { return }

    if identifier == Routes.About.rawValue {
        ...
    } else if identifier == Routes.Home.rawValue {
        ...
    } else if identifier == Routes.Login.rawValue {
        ...
    }
}

The rawValue property returns the String value of the enum and we eliminate the change of typing it wrong. Awesome!

Conclusion

It is a very good practice to never rely on Strings to do conditionals because hey we're human and we fail all the time. Let's just help the compiler help us by preventing our own bugs.

That's it! I hope you liked the article and if you have anything to discuss or wanna give some feedback feel free to comment below, I will be happy to chat with you!

Simple but powerful Coding Practices that you can adopt immediately: Consistent naming conventions

Darlan Tódero ten Caten — Thu, 10 Dec 2020 23:20:12 +0000

I already wrote about naming conventions in a past article but I wanna explore a little more because I think this topic is very important for every developer.

The "One word per concept" rule

Consider the following code:

class UserManager {
    func getData() { ... }
}
class CategoryController {
    func requestData() { ... }
}
class PostStore {
    func retrieveData() { ... }
}

Can you see any difference between get, request, and retrieve in such a scenario?
And how about the Manager, Controller, and Store? What is the essential difference between them?

Essentially they are all the same and you must stick with just one word for each concept in the whole project to create a consistent naming throughout the project. Let's refactor it:

class UserStore {
    func getData() { ... }
}
class CategoryStore {
    func getData() { ... }
}
class PostStore {
    func getData() { ... }
}

Using the same word for each concept will save you tons of time for thoughts like "should I call get or request function now?". Time is money, you know!

Don't confuse the reader

You are a reader from your own code. In fact, as developers we are constantly reading old code to write new code. And if you're not working alone on the project, you have other developers who constantly read your code as well.

As authors, our goal is to write code that is easy to read and understand code all the time.

We want our code to be a quick skim, not an intense study. - Robert C. Martin

Using the same term for two different purposes is essentially a pun and can lead the reader to confusion:

class UserStore {
    var users = [String]()

    func add(user: String) {
        users.append(user)
    }
}
class CountStore {
    var counter = 0

    func add(value: Int) {
        counter += value
    }
}

Two classes with an add method. Consistent name with different results. The first one is used to append a String to a list (Array) of Strings. The second one is used to sum the value with another existing property value. This is bad.

Know your readers

The people who will read your code will be mainly developers. So go ahead and use computer science terms, algorithm names, math terms, and so forth to name things.

The LoginViewModel is easy to understand by any developer who is familiar with the view model pattern. The same is valid for Service, Controller, Interface, etc.

If you are just starting in this industry you can easily find lists of common words in our universe.

Conclusion

Naming things is quite difficult but it is a very necessary skill for any developer. Experience makes it easier over time but we always need to try to get out of the comfort zone and improve this essential skill.

Quick tip: Improve your code blocks with a language tag

Darlan Tódero ten Caten — Sun, 06 Dec 2020 04:09:14 +0000

Today I learned something very useful about code blocks on Dev.to (and it probably works on other blogging platforms too) that I immediately wanted to share with the community.

To explain this let me first show the result without the language tag:

func calculateHourlyPay(for workingHours: Int, at dayOfWeek: String) -> Double {
    let paymentPerHour: Double = 30

    let normalHours: Double = workingHours > 8 ? 8 : Double(workingHours)
    let overtimeHours = workingHours > 8 ? Double(workingHours - 8) : 0

    var payment: Double = 0

    if dayOfWeek == "sun" {
        payment = normalHours * paymentPerHour * 2
        payment += overtimeHours * paymentPerHour * 2 * 1.5
    } else if dayOfWeek == "sat" {
        payment = normalHours * paymentPerHour * 1.2
        payment += overtimeHours * paymentPerHour * 1.2 * 1.5
    } else {
        payment = normalHours * paymentPerHour
        payment += overtimeHours * paymentPerHour * 1.5
    }

    return payment
}

Notice how the code was misinterpreted, with little color distinction. The code block did not understand that I wrote code in Swift. Let's help it understand it by adding the language tag:

func calculateHourlyPay(for workingHours: Int, at dayOfWeek: String) -> Double {
    let paymentPerHour: Double = 30

    let normalHours: Double = workingHours > 8 ? 8 : Double(workingHours)
    let overtimeHours = workingHours > 8 ? Double(workingHours - 8) : 0

    var payment: Double = 0

    if dayOfWeek == "sun" {
        payment = normalHours * paymentPerHour * 2
        payment += overtimeHours * paymentPerHour * 2 * 1.5
    } else if dayOfWeek == "sat" {
        payment = normalHours * paymentPerHour * 1.2
        payment += overtimeHours * paymentPerHour * 1.2 * 1.5
    } else {
        payment = normalHours * paymentPerHour
        payment += overtimeHours * paymentPerHour * 1.5
    }

    return payment
}

Wow, much better!

How to do this? Here's how I wrote the first code block without a language tag:

Now the enhanced version with a language tag:

Conclusion

Code blocks are great and very useful for writing sample code in technical articles. But sometimes it can't understand the code language and it is better to explicitly indicate it by adding a language tag.

Simple but powerful Coding Practices that you can adopt immediately: Indentation & whitespace

Darlan Tódero ten Caten — Thu, 03 Dec 2020 02:34:25 +0000

Continuing the powerful coding practices series, today I will talk with two simple concepts that can greatly improve the readability of our code.

Maintaining proper indentation

A source file is a hierarchy rather like an outline. Each level of this hierarchy is a scope into which names can be declared and in which declarations and executable statements are interpreted. - quote from Clean Code book - Robert C. Martin

We use indentation to visually identify these hierarchies in our code. A correctly indented code is easy to read from top to bottom and we must keep it consistent throughout the whole project.

Consider the following code:

class Payment {
let paymentPerHour: Double

init(paymentPerHour: Double) {self.paymentPerHour = paymentPerHour}

    private func normalHours(from workingHours: Int) -> Double {
return workingHours > 8 ? 8 : Double(workingHours)}

private func overtimeHours(from workingHours: Int) -> Double {
        return workingHours > 8 ? Double(workingHours - 8) : 0}}

Pretty bad, right? Our brain cannot find a pattern to identify where every method starts and finishes. It is very hard to read this code. And hard to read means that it's very hard to maintain it because we're always reading code to write new code.

Let's fix it with proper identation:

class Payment {
    let paymentPerHour: Double

    init(paymentPerHour: Double) {
        self.paymentPerHour = paymentPerHour
    }

    private func normalHours(from workingHours: Int) -> Double {
        return workingHours > 8 ? 8 : Double(workingHours)
    }

    private func overtimeHours(from workingHours: Int) -> Double {
        return workingHours > 8 ? Double(workingHours - 8) : 0
    }
}

Much better! Compare the two examples. The code is the same in both but the second one is correctly indented.

Nowadays almost every code editor in the market can automatically apply the indentation to our code. Also, you can use tools to automate it for you, like Prettier.

Using whitespace to create vertical separation

Nearly all code is read left to right and top to bottom. Every line represents a statement or expression and every group of lines must represent a complete thought.

Add whitespace (or blank line if you prefer) to separate these thoughts. The code became more readable.

What if our previous code was written without any whitespace?

class Payment {
    let paymentPerHour: Double
    init(paymentPerHour: Double) {
        self.paymentPerHour = paymentPerHour
    }
    private func normalHours(from workingHours: Int) -> Double {
        return workingHours > 8 ? 8 : Double(workingHours)
    }
    private func overtimeHours(from workingHours: Int) -> Double {
        return workingHours > 8 ? Double(workingHours - 8) : 0
    }
}

Even if it is well indented it is difficult to read because we have no clues as to where each thought (methods in this code) begins or ends. Ok, the colors in the code editors help a lot to identify these things (init, private func, etc), but correct use of whitespace can greatly improve readability.

Conclusion

In this article, I wrote about the usage of indentation and whitespace to improve code readability. I hope you got some insights from it.

This article is the third in the series where I am writing about best practices on coding.

If you have any questions or want to give any feedback feel free to comment below. I will be happy to discuss this with you.

If you enjoy my work you can subscribe to be notified when I publish new articles.

Thank you! Have a great day!

Simple but powerful Coding Practices that you can adopt immediately: Classes and Functions

Darlan Tódero ten Caten — Fri, 27 Nov 2020 11:44:46 +0000

Functions are one of the best and most essential tools we have to do our job as developers. Probably we all learned to use them to remove duplicated code, grouping instructions together to easy reuse.

Classes are generally used to group related properties and functions (usually called "methods" in this case).

These two tools help us to create better and more organized code when used fairly following good coding principles.

Let's talk about some.

Pure functions are better

A function is considered pure when it doesn't have external dependencies that can modify its result. Their output value must always by equal when called with the same input.

Consider the example:

func sum(_ a: Int, plus b: Int) -> Int {
    return a + b
}
func add(value: Int) -> Int {
    return totalValue + value
}

Can you identify if the functions above are pure?

The sum function is pure because it always produces the same result when called with the same inputs, no matter how many times you call it.

func sum(_ a: Int, plus b: Int) -> Int {
    return a + b
}
sum(15, plus: 20) // 35
sum(15, plus: 20) // 35
sum(100, plus: 20) // 120
sum(100, plus: 20) // 120

But the add function is not pure because it uses an external variable named "totalValue" which can be different in every call. The function cannot control what happens to the dependency and therefore cannot guarantee the result will be consistent.

var totalValue = 0

func add(value: Int) -> Int {
    return totalValue + value
}

add(value: 10) // 10
totalValue = 20
add(value: 10) // 30
totalValue = add(value: 20) // 40
add(value: 20) // 60

As you can see, impure functions can hide hard to track bugs because the dependencies that are totally out of their control.

It is much easy to test and maintain a pure function.

Keep them as small as possible

When we start coding something it is quite common to create large and confusing functions that do everything. This is normal while we are trying to solve a problem and still don't know exactly how to do it. We need to think, implement, and test to make sure it works as it should.

However, when the code is working as expected the work is not yet complete. Now it is time to refactor it cleaning the large confusing functions by breaking them into smaller ones.

Consider the following fictional problem: the ACME company pays its employees for hours of work in the day. On weekdays the total payment must be $30 per hour. On Saturdays add a bonus of 20% and on Sundays, the payment must be doubled. Let's code it:

func calculateHourlyPay(for workingHours: Int, at dayOfWeek: String) -> Double {
    let paymentPerHour: Double = 30

    if dayOfWeek == "sun" {
        return Double(workingHours) * paymentPerHour * 2
    }
    if dayOfWeek == "sat" {
        return Double(workingHours) * paymentPerHour * 1.2
    }

    return Double(workingHours) * paymentPerHour
}

let sunPayment = calculateHourlyPay(for: 10, at: "sun") // 600
let monPayment = calculateHourlyPay(for: 10, at: "mon") // 300
let tuePayment = calculateHourlyPay(for: 10, at: "tue") // 300
let wedPayment = calculateHourlyPay(for: 10, at: "wed") // 300
let thuPayment = calculateHourlyPay(for: 10, at: "thu") // 300
let friPayment = calculateHourlyPay(for: 10, at: "fri") // 300
let satPayment = calculateHourlyPay(for: 10, at: "sat") // 360

Looking good. But now the customer has asked to calculate overtime hours that exceed the first 8 hours of work. Overtime hours pay 50% more.

Ok, should be easy:

func calculateHourlyPay(for workingHours: Int, at dayOfWeek: String) -> Double {
    let paymentPerHour: Double = 30

    let normalHours: Double = workingHours > 8 ? 8 : Double(workingHours)
    let overtimeHours = workingHours > 8 ? Double(workingHours - 8) : 0

    var payment: Double = 0

    if dayOfWeek == "sun" {
        payment = normalHours * paymentPerHour * 2
        payment += overtimeHours * paymentPerHour * 2 * 1.5
    } else if dayOfWeek == "sat" {
        payment = normalHours * paymentPerHour * 1.2
        payment += overtimeHours * paymentPerHour * 1.2 * 1.5
    } else {
        payment = normalHours * paymentPerHour
        payment += overtimeHours * paymentPerHour * 1.5
    }

    return payment
}

let sunPayment = calculateHourlyPay(for: 10, at: "sun") // 660
let monPayment = calculateHourlyPay(for: 10, at: "mon") // 330
let tuePayment = calculateHourlyPay(for: 10, at: "tue") // 330
let wedPayment = calculateHourlyPay(for: 10, at: "wed") // 330
let thuPayment = calculateHourlyPay(for: 10, at: "thu") // 330
let friPayment = calculateHourlyPay(for: 10, at: "fri") // 330
let satPayment = calculateHourlyPay(for: 10, at: "sat") // 396

Awesome! Ready to ship, right? No... not really.

Now the function is large and full of calculations that can be difficult to read if you don't understand exactly what's going on. I guarantee you: if you need to do changes to this code in the future you will need a couple of minutes reading this to understand. Waste of time. It is better to refactor and write it better now that it is still fresh in our minds.

Which brings us to the next tip:

Classes and Functions must have only one purpose

The S in SOLID principles stands for Single-responsibility. That is, do just one thing.

Look at our last code. Our function does a lot of things right now:

keep the payment per hour value as a constant (hard to update);
calculate normal and overtime work hours;
verify the day of the week;
calculate normal hours payment;
calculate overtime hours payment;
sum normal and overtime payments to return.

Six responsibilities. We can do better! Let's refactor it:

class Payment {
    let paymentPerHour: Double

    init(paymentPerHour: Double) {
        self.paymentPerHour = paymentPerHour
    }

    func calculateHourlyPay(for workingHours: Int, at dayOfWeek: String) -> Double {
        let normalHours: Double = workingHours > 8 ? 8 : Double(workingHours)
        let overtimeHours = workingHours > 8 ? Double(workingHours - 8) : 0

        var payment: Double = 0

        if dayOfWeek == "sun" {
            payment = normalHours * paymentPerHour * 2
            payment += overtimeHours * paymentPerHour * 2 * 1.5
        } else if dayOfWeek == "sat" {
            payment = normalHours * paymentPerHour * 1.2
            payment += overtimeHours * paymentPerHour * 1.2 * 1.5
        } else {
            payment = normalHours * paymentPerHour
            payment += overtimeHours * paymentPerHour * 1.5
        }

        return payment
    }
}

First, we refactored it to be a Class and moved the paymentPerHour constant to be a property. Now we can easily change this property value whenever necessary or even reuse the class with different paymentPerHour values. Let's continue:

class Payment {
    let paymentPerHour: Double

    init(paymentPerHour: Double) {
        self.paymentPerHour = paymentPerHour
    }

    private func normalHours(from workingHours: Int) -> Double {
        return workingHours > 8 ? 8 : Double(workingHours)
    }

    private func overtimeHours(from workingHours: Int) -> Double {
        return workingHours > 8 ? Double(workingHours - 8) : 0
    }

    func calculateHourlyPay(for workingHours: Int, at dayOfWeek: String) -> Double {
        let normalHours = self.normalHours(from: workingHours)
        let overtimeHours = self.overtimeHours(from: workingHours)

        var payment: Double = 0

        if dayOfWeek == "sun" {
            payment = normalHours * paymentPerHour * 2
            payment += overtimeHours * paymentPerHour * 2 * 1.5
        } else if dayOfWeek == "sat" {
            payment = normalHours * paymentPerHour * 1.2
            payment += overtimeHours * paymentPerHour * 1.2 * 1.5
        } else {
            payment = normalHours * paymentPerHour
            payment += overtimeHours * paymentPerHour * 1.5
        }

        return payment
    }
}

Second, we created two private methods to calculate normal and overtime hours. Did you notice that the calculateHourlyPay method is losing its responsibilities? Let's move on:

class Payment {
    let paymentPerHour: Double

    init(paymentPerHour: Double) {
        self.paymentPerHour = paymentPerHour
    }

    private func normalHours(from workingHours: Int) -> Double {
        return workingHours > 8 ? 8 : Double(workingHours)
    }

    private func overtimeHours(from workingHours: Int) -> Double {
        return workingHours > 8 ? Double(workingHours - 8) : 0
    }

    private func calculateNormalHoursPayment(for hours: Double, withBonus bonus: Double = 1) -> Double {
        return hours * self.paymentPerHour * bonus
    }

    private func calculateOvertimeHoursPayment(for hours: Double, withBonus bonus: Double = 1) -> Double {
        return hours * self.paymentPerHour * bonus * 1.5
    }

    func calculateHourlyPay(for workingHours: Int, at dayOfWeek: String) -> Double {
        let normalHours = self.normalHours(from: workingHours)
        let overtimeHours = self.overtimeHours(from: workingHours)

        var payment: Double = 0

        if dayOfWeek == "sun" {
            payment = calculateNormalHoursPayment(for: normalHours, withBonus: 2)
            payment += calculateOvertimeHoursPayment(for: overtimeHours, withBonus: 2)
        } else if dayOfWeek == "sat" {
            payment = calculateNormalHoursPayment(for: normalHours, withBonus: 1.2)
            payment += calculateOvertimeHoursPayment(for: overtimeHours, withBonus: 1.2)
        } else {
            payment = calculateNormalHoursPayment(for: normalHours)
            payment += calculateOvertimeHoursPayment(for: overtimeHours)
        }

        return payment
    }
}

Third, we created two more private methods to take care of calculating the payment for normal and overtime hours. Okay, our code is now bigger in the number of lines, but this is not the metric we should consider: we now have four small private methods (functions) that are easy to read and understand and our main method calculateHourlyPay has ** fewer responsibilities**:

verify the day of the week;
delegate the calculations for other methods;
sum normal and overtime payments to return.

Just three responsibilities now. I really hope that you get to see the improvement we've made here. Let's finish it?

class Payment {
    let paymentPerHour: Double

    init(paymentPerHour: Double) {
        self.paymentPerHour = paymentPerHour
    }

    private func normalHours(from workingHours: Int) -> Double {
        return workingHours > 8 ? 8 : Double(workingHours)
    }

    private func overtimeHours(from workingHours: Int) -> Double {
        return workingHours > 8 ? Double(workingHours - 8) : 0
    }

    private func calculateNormalHoursPayment(for hours: Double, withBonus bonus: Double = 1) -> Double {
        return hours * self.paymentPerHour * bonus
    }

    private func calculateOvertimeHoursPayment(for hours: Double, withBonus bonus: Double = 1) -> Double {
        return hours * self.paymentPerHour * bonus * 1.5
    }

    private func calculateHorlyPay(for workingHours: Int, withBonus bonus: Double = 1) -> Double {
        let normalHours = self.normalHours(from: workingHours)
        let overtimeHours = self.overtimeHours(from: workingHours)

        let normalPay = self.calculateNormalHoursPayment(for: normalHours, withBonus: bonus)
        let overtimePay = self.calculateOvertimeHoursPayment(for: overtimeHours, withBonus: bonus)

        return normalPay + overtimePay
    }

    func bonus(for dayOfWeek: String) -> Double {
        if dayOfWeek == "sun" {
            return 2
        }
        if dayOfWeek == "sat" {
            return 1.2
        }
        return 1
    }

    func calculateHourlyPay(for workingHours: Int, at dayOfWeek: String) -> Double {
        return calculateHorlyPay(
            for: workingHours,
            withBonus: self.bonus(for: dayOfWeek)
        )
    }
}

let payment = Payment(paymentPerHour: 30)

let sunPayment = payment.calculateHourlyPay(for: 10, at: "sun") // 660
let monPayment = payment.calculateHourlyPay(for: 10, at: "mon") // 330
let tuePayment = payment.calculateHourlyPay(for: 10, at: "tue") // 330
let wedPayment = payment.calculateHourlyPay(for: 10, at: "wed") // 330
let thuPayment = payment.calculateHourlyPay(for: 10, at: "thu") // 330
let friPayment = payment.calculateHourlyPay(for: 10, at: "fri") // 330
let satPayment = payment.calculateHourlyPay(for: 10, at: "sat") // 396

Yes! I'm now very happy with this code. Our main (and the unique not private) method is very small and does just one thing: it delegates the calculation for other specific methods and returns the result.

Conclusion

Functions and Classes can be the source of nasty bugs if written without care. But they can be the best thing in our code if used following the principles discussed in this article.

I sincerely hope that you had some insights and learning from reading this article. So far it is the article that I dedicated myself the most to writing!

If you still don't already have it I strongly recommend that you read the Clean Code book (affiliate link). It is a must-read for developers and most of the contents of this article came from what I learned from it.

This article is the second in the series where I am writing about best practices on coding.

If you have any questions or want to give any feedback feel free to comment below. I will be happy to discuss this with you.

If you enjoy my work you can subscribe to be notified when I publish new articles.

Thank you! Have a great day!

Lessons I learned from watching the Essential Developer's Quiz App series

Darlan Tódero ten Caten — Sun, 22 Nov 2020 15:06:30 +0000

Recently I got a new job as an iOS developer and felt the need to refresh my knowledge in Swift because I was mainly coding in Javascript and Flutter for the past two years in my startup.

So I did some research and luckily found Caio and Mike Essential Developer YouTube Channel with an amazing playlist creating a Quiz App with advanced techniques like TDD & Clean Architecture. I learned a lot from them, so I will write about it here so I never forget the lessons learned.

I highly recommend that you watch their series too. I assure you will learn a lot too, even if you don't work with Swift because the concepts explained can be applied in any language. You can find a link to the first episode at the end of this article.

TDD is awesome. You must learn how to use it

It had been about two years since I knew I needed to write unit tests on my code. I studied several techniques for this, but I couldn't find a way to put It into practice. My code was difficult to test and I didn't have the tools and the knowledge to write them.

But the way Caio and Mike write tests is just... easy. Easy to follow, easy to understand, and easy to maintain.

They used TDD approach to develop the whole app, starting with the game's Engine. Even ViewControllers were covered by tests.

The process follows the following steps:

1- Red: you write a very simple and minimum test to validate something (usually a Class or Struct). It will be red because the system under test (known as SUT) still doesn't exist (compile error). The test will crash.

import XCTest
@testable import QuizEngine

class FlowTest: XCTestCase {
    func test_start_withNoQuestions_doesNotHaveQuestions() {
        let sut = Flow(questions: [])

        XCTAssertTrue(sut.questions.isEmpty)
    }
}

2- Yellow: you create the SUT (your Class our Struct you are testing) and the methods it needs just to remove compile errors to build. The test must fail.

class Flow {
    let questions: [String]

    init(questions: [String]) {}
}

3- Green: you finish the implementation of the SUT with the minimum necessary code just to pass the test. Don't think ahead trying to implement everything upfront. Let the tests guide you.

class Flow {
    let questions: [String]

    init(questions: [String]) {
        self.questions = []
    }
}

4- Yellow again: add another test to continue advancing towards your goal:

import XCTest
@testable import QuizEngine

class FlowTest: XCTestCase {
    func test_start_withNoQuestions_doesNotHaveQuestions() {
        let sut = Flow(questions: [])

        XCTAssertTrue(sut.questions.isEmpty)
    }

    func test_start_withOneQuestion_doesHaveOneQuestion() {
        let sut = Flow(questions: ["Q1"])

        XCTAssertEqual(sut.questions, ["Q1"])
    }
}

5- Green again: fix the init to properly function as expected and the two tests must pass now.

class Flow {
    let questions: [String]

    init(questions: [String]) {
        self.questions = questions
    }
}

6- Repeat: continue repeating the process: add new tests that will fail, implement the code that will make them pass.

Sometimes the process seems silly and unnecessary, but you need to practice to make it a habit. It is a total change in the way of writing code.

But I guarantee you: the very first time a test saves you from yourself when changing
a code you will be very grateful you have written it previously.

Refactoring isn't scary if you have test coverage

In season two Caio and Mike refactored the entire game Engine, deprecating everything in the core to create an enhanced version of it, introducing the Quiz class.

We've all been there: we've decided that we need to rewrite an entire class because its design is very bad. Then we start changing everything and then we have multiple errors to handle, changing code everywhere to match the refactor we did. It is a mess. And it will produce multiple new bugs, you know that! So much so that many times we decided to simply give up refactoring and continue to maintain bad code. Right?

Well, Caio and Mike approach to refactor the game Engine is very awesome. They start deprecating class and functions to produce warning errors while maintaining backward compatibility. The first rule is: don't break the existing code for current users.

@available(*, deprecated, message: "use Quiz instead")
public class Game <R: Router> {
    ...
}

@available(*, deprecated, message: "use Quiz.start instead")
public func startGame() {
    ...
}

Then they create the new classes and functions with new behaviors, continuing step by step to replace the old behaviors. Here the tests play an important role: they guarantee the old code continues to work regardless of what changed.

When refactoring ends, clients who depend on the Engine still work in exactly the same way. Zero bugs produced. They now just got deprecated code warnings with instructions to update to the new features.

Commit very often. Commit everything

During season two I also learned with them the importance of keeping commits small and to commit every change we made.

The reason is very simple: small commits are easy to read and understand. You can easily open it and discover the changes it made to the code. Also, I think you get a better understanding of your thought process in that code by just reading the small commits.

Business rules code should be platform agnostic

We can have many benefits if we create our business rules code without any platform dependency, separating it from everything else:

They are easy to write and maintain;
You can easily re-use the code to publish other apps like macOS, watchOS, tvOS, etc;
You can even re-use the code in a new project. For example, the QuizEngine that we build in this series can be used to create survey apps and multiple types of quiz games with the very same core code.

In the iOS / Swift world, we have another powerful benefit: we can run the tests of the core very very fast because we create it targeting the macOS, which runs much faster than an iOS target app (which depends on Device or iOS Simulator).

Good code survives changes in the platform or programming language new versions

Caio and Mike started the series in 2017 when Swift 3 was the newest version. Today we have Swift 5.2 as the newest version.

It is not uncommon in this type of scenario that old code created in such different versions does not work correctly in the current version and are hard to upgrade. This kind of problem scales with every third party dependency the code has. But if we keep our code with minimum dependency (the business rules shouldn't have any) we can update with no pain.

And again, the tests help a lot in this case, working as a safety net to update without fear.

Clean Architecture provides a SOLID foundation to follow

It is hard to adopt the Clean Architecture, it seems like so much work to be effective and productive. It is very fast to simply create classes and functions that are directly dependent on each other or simply put all the code in the same file/class. But as soon as that code grows, the costs to maintain it grows exponentially as well.

The SOLID principles provide a bunch of ways to create easier to maintain, extend, and test code that pays the cost in the long run because you can continue to work fast in it without regressions.

In my previous article, I started a series with some tips towards this.

I highly recommend that you learn these concepts and try to implement them in your own code.

Conclusion

Learning from highly skilled developers who know how to teach is very very helpful. Caio and Mike certainly know what they are doing and I am very happy to have found their content.

Currently, they started season three that I still need to watch. I'm sure I'll learn a few more things from them and maybe I'll write another article in the future.

Enjoy you too:

How to Build iOS Apps with Swift, TDD & Clean Architecture

Disclaimer: this is not a sponsored article. I talked to Caio and asked for permission to share it here simply because I really liked the content.

Simple but powerful Coding Practices that you can adopt immediately: Naming and DRY

Darlan Tódero ten Caten — Tue, 17 Nov 2020 04:44:42 +0000

Everyone can write code with the right focus to learn the basics. Good developers can write code that solves big problems in real life. But the best developers don't just write awesome code, their code is easily read and understood by other developers.

Take some time to reflect: while coding you use more time writing or reading existing code? I bet it is the second option.

“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 it easier to write.” ― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

As software developers, we must always seek to improve our code every day.

So in this series of articles, I will describe some good practices that you can (and probably should) adopt immediately.

Master the "naming skill"

Names are everywhere: variables, functions, arguments, classes, packages, directories, source files, etc.

Once I understood this concept I really think it is the most important skill that a developer needs to master. I know, it is very hard to master it, but you must practice it!

Consider the following example:

func fn(a: Int, b: Int) -> Int {
    var c = 0
    for i in a...b {
        if i % 2 == 0 {
            c = c + 1
        }
    }
    return c
}
func fn2(a: Int, b: Int) -> Int {
    var c = 0
    for i in a...b {
        if i % 2 != 0 {
            c = c + 1
        }
    }
    return c
}

let r1 = fn(a: 0, b: 100)
print(r1) // 51

let r2 = fn2(a: 0, b: 100)
print(r2) // 50

Can you understand what these two functions do? Can you at least see the difference between the two? I bet you don't!

Well, let's try a new version:

func countEvenNumbers(from: Int, to: Int) -> Int {
    var count = 0
    for index in from...to {
        if index % 2 == 0 {
            count = count + 1
        }
    }
    return count
}
func countOddNumbers(from: Int, to: Int) -> Int {
    var count = 0
    for index in from...to {
        if index % 2 != 0 {
            count = count + 1
        }
    }
    return count
}

let totalEvenNumbers = countEvenNumbers(from: 0, to: 100)
print(totalEvenNumbers) // 51

let totalOddNumbers = countOddNumbers(from: 0, to: 100)
print(totalOddNumbers) // 50

And now? Can you understand the code? I bet that even if you don't know Swift you can understand him simply because all the names are clear, self-explanatory.

For me the main rule when naming things is: always prefer a big but self-explanatory name over a small name that is impossible to understand for itself.

If you ask me, the best source to learn this skill is Robert C. Martin's Clean Code book.

Always avoid code duplication

The DRY rule is mandatory: don't repeat yourself!

Every time you find yourself copying and pasting your own code take a deep breath and ask yourself: why am I doing this?

If you are just testing new code, it is fine to duplicate it. However the moment you realize that the code is ready you must transform the duplicate code into a utility function (or even a class) to reuse it, removing the duplication.

Can you see duplicated code in our previous example? The two functions are practically the same, only the condition changes. Let's try to improve it?

func loopAndCount(_ from: Int, _ to: Int, when: (Int) -> Bool) -> Int {
    var count = 0
    for index in from...to {
        if when(index % 2) {
            count = count + 1
        }
    }
    return count
}
func countEvenNumbers(from: Int, to: Int) -> Int {
    func when(result: Int) -> Bool {
        return result == 0
    }
    return loopAndCount(from, to, when: when)
}
func countOddNumbers(from: Int, to: Int) -> Int {
    func when(result: Int) -> Bool {
        return result != 0
    }
    return loopAndCount(from, to, when: when)
}

Now we introduce the loopAndCount utility function and move all the duplicated logic to it, passing the condition using a Closure as an argument named when.

In Swift, we can make it even smaller (and still quite readable):

func loopAndCount(_ from: Int, _ to: Int, when: (Int) -> Bool) -> Int {
    var count = 0
    for index in from...to {
        if when(index % 2) {
            count = count + 1
        }
    }
    return count
}
func countEvenNumbers(from: Int, to: Int) -> Int {
    return loopAndCount(from, to) { $0 == 0 }
}
func countOddNumbers(from: Int, to: Int) -> Int {
    return loopAndCount(from, to) { $0 != 0 }
}

Now, if for any reason we need to change the code logic we just need to update it in one place. This is the magic behind DRY. So don't repeat yourself!

Avoid using ELSE, write a better code

Darlan Tódero ten Caten — Fri, 13 Nov 2020 20:11:48 +0000

At the beginning of our career, every developer learns the if else conditionals and immediately start using it everywhere. I would say it is normal because the use case is quite simple to understand, "if the condition is true, then do this, otherwise, do something else".

You can even easily identify a code written by a junior developer just reading all the if else used in their code. This is normal and part of the learning process. But as we gain more experience we learn better ways to do the same things.

The problem with the else is that it doesn't have the proper context as it's own, and you always must back to if to remember what it does. And, in many cases, it is completely useless, as I will show you.

The not necessary case

Consider the following code:

func multiply(ifExists value: Int?, by: Int = 2) -> Int {
    if let value = value {
        return value * by
    } else {
        return 0
    }
}

It's a simple Swift function with an optional parameter (the Int? describes it if you are new to Swift).
If the parameter is not nil (mainly known as null) multiply it by the second parameter (which is not optional but have a default value 2). But if the parameter is nil then return zero as a result.

Wait a minute... is the else statement necessary in this code? It is not. We can easily refactor this to return right after the if statement:

func multiply(ifExists value: Int?, by: Int = 2) -> Int {
    if let value = value {
        return value * by
    }
    return 0
}

Much cleaner, right?

In Swift, you can also use guard, if you prefer (I like this one):

func multiply(ifExists value: Int?, by: Int = 2) -> Int {
    guard let value = value else { return 0 }
    return value * by
}

The return earlier case

Every time you collect user input you will need to validate it before using it. It is very common to see codes like that:

func submit(email: String, phone: String) -> Void {
    if isValidEmail(email) {
        if isValidPhone(phone) {
            doSomething(email: email, phone: phone)
        } else {
            displayPhoneError()
        }
    } else {
        displayEmailError()
    }
}

Two properties and two else cases. It works, but we have to follow two indentation levels to read every line and understand what is going on.

I think it is better to read if we refactor the function to:

func submit(email: String, phone: String) -> Void {
    if !isValidEmail(email) {
        displayEmailError()
        return
    }
    if !isValidPhone(phone) {
        displayPhoneError()
        return
    }

    doSomething(email: email, phone: phone)
}

Now we are using return inside if to stop the execution of the function when the input is invalid. This way we maintain our code with just one indentation level, which is easy to read top to bottom.

Conclusion

The else statement is a tool we have to write code but most of the time it is useless and you should avoid using it. We have other (and better) options.

Every time I write else in my code I immediately ask myself: is it really necessary? And then most of the time I just refactor it to remove it.