
In this series, I will describe some good practices that you can (and probably should) adopt immediately to write better code.



I already wrote about naming conventions in a [past article](/blog/simple-but-powerful-coding-practices-that-you-can-adopt-immediately-naming-and-dry) 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:

```swift
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:

```swift
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:

```swift
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](https://www.wholewhale.com/tips/developer-terms-glossary/) 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.


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


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:

```swift
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:

```swift
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?

```swift
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: Indentation & whitespace


**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:

```swift
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.

```swift
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.

```swift
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:

```swift
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:

```swift
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](https://en.wikipedia.org/wiki/SOLID) 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:

```swift
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:

```swift
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:

```swift
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?

```swift
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](https://amzn.to/2V8WWEE) 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!


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


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**!


Article Series

Simple But Powerful Coding Practices