Why guard statements should be avoided in Swift

Since the guard statement appeared in Swift, it has caused a lot of discussion. To be honest, guard does simplify the code and improve the readability of the code, but is it a panacea?

Small Functions

There is also a lot of discussion about the size of functions. Obviously, function bodies should be short, and the shorter the better. No one wants to read, understand, or refactor large functions. But how big should a function be?

The first criterion for a function is that it should be short. The second criterion is that it should be even shorter. ---Robert C. Martin

More specifically, Martin believes that functions should be less than six lines in length and never more than ten lines.

Although the rules are simple, the effect is significant. You can see that the code immediately becomes much easier to understand. Before, you needed to remember a function with 30 lines of code, several indentation levels, and several intermediate variables. Now you only need to remember ten functions with clear names.

Single Responsibility

Single responsibility has been talked about for a long time. This rule applies not only to objects, but also to functions. Obviously, each function should do only one thing, but people break this rule again and again, mostly because of the size of the function. If you refactor a 30-line function into ten 3-line functions, then the single responsibility rule will naturally be followed at the function level.

Single layer of abstraction

People don't talk much about single-level abstraction in functions. It is a tool that helps to write single-responsibility functions.

What is single-level abstraction? Simply put, code at a high level of abstraction, such as controlling a process, should not be mixed with small details, such as variable increments or Boolean value checks. For example.

The following example is from The Swift Programming Language book.

 struct Item {
 var price: Int
 var count: Int
 } 
  
 enum VendingMachineError: ErrorType {
 case InvalidSelection
 case InsufficientFunds(coinsNeeded: Int)
 case OutOfStock
 } 
  
 class VendingMachine {
 var inventory = [
 "Candy Bar" : Item(price: 12 , count: 7 ),
 "Chips" : Item(price: 10 , count: 4 ),
 "Pretzels" : Item(price: 7 , count: 11 )
 ] 
  
 var coinsDeposited = 0   
  
    func dispense(snack: String) {
        print( "Dispensing \(snack)" )
 } 
  
    func vend(itemNamed name: String) throws {
        guard var item = inventory[name] else {
 throw VendingMachineError.InvalidSelection
 } 
  
 guard item.count > 0   else {
 throw VendingMachineError.OutOfStock
 } 
  
        guard item.price <= coinsDeposited else {
 throw VendingMachineError.InsufficientFunds(coinsNeeded: item.price - coinsDeposited)
 } 
  
        coinsDeposited -= item.price
 --item.count
        inventory[name] = item
 dispense(name)
 }
 }

Of course, vend(itemNamed:) is just one example of using the gaured statement, but you’ll often see similar functions in production code. This function exhibits the three problems mentioned above:

1. It is quite long, sixteen lines long, with many sections separated by blank lines.
2. It does several things: get a product by name, verify the legitimacy of the parameters, and then the logic of selling the product.
3. It has several levels of abstraction. The highest level selling process is hidden in the lower level details, such as Boolean validation, use of special constants, mathematical operations, etc.

What does this function look like after refactoring?

 func vend(itemNamed name: String) throws {
    let item = try validatedItemNamed(name)
    reduceDepositedCoinsBy(item.price)
    removeFromInventory(item, name: name)
 dispense(name)
 } 
  
 private func validatedItemNamed(name: String) throws -> Item {
    let item = try itemNamed(name)
 try validate(item)
 return item
 } 
  
 private func reduceDepositedCoinsBy(price: Int) {
 coinsDeposited -= price
 } 
  
 private func removeFromInventory(var item: Item, name: String) {
 --item.count
 inventory[name] = item
 } 
  
 private func itemNamed(name: String) throws -> Item {
 if let item = inventory[name] {
 return item
 } else {
 throw VendingMachineError.InvalidSelection
 }
 } 
  
 private func validate(item: Item) throws {
 try validateCount(item.count)
 try validatePrice(item.price)
 } 
  
 private func validateCount(count: Int) throws {
 if count == 0 {
 throw VendingMachineError.OutOfStock
 }
 } 
  
 private func validatePrice(price: Int) throws {
 if coinsDeposited < price {
 throw VendingMachineError.InsufficientFunds(coinsNeeded: price - coinsDeposited)
 }
 }

Although the total number of lines has increased, you should remember that the number of lines of code is not its ultimate goal.

The refactored code has several advantages over the old version:

1. The core sell function has become smaller and contains only the high-level logic of the steps to sell an item. If the reader is not interested in the details, she can understand the selling process by quickly looking at this high-level function.
2. These functions follow the Single Responsibility Principle better. Some of them could be broken down even smaller, but even in their current form they are much easier to read and understand. They break up the old large string of code into smaller, more understandable chunks.
3. Each function is responsible for a single level of abstraction. The reader can move between levels as needed. What is the selling process like? Determine if the product is valid based on the name, then reduce the customer's balance, remove the product from the inventory, and finally display that the product has been sold? How do you know if the product is valid? By checking the quantity and price. How do you know the exact quantity? By comparing it with 0. If the reader has no interest in the details, he can completely ignore this part.

in conclusion

Guard statements are handy for reducing nesting of structures and functions, but the problem is not guard itself, but its use. Guard statements will force you to write large functions that do several things and have multiple levels of abstraction. As long as you keep your functions small and clear, you don't need guard statements at all.

Related Reading

• View Event Testing in Swift
• Humble Object Pattern in Swift
• Safer UIViewController Creation When Using Storyboards
• Dependency Injection in View Controllers
• Dependency Injection in Swift