Matthew's Dev Blog

Enums are meant for switching

I'm rewriting Nearly Departed, and working on a large iOS project in my day-job. While working on both of those projects, I've started to rely on two unofficial rules for enumerations:

  1. Enumeration values should always be checked with switch, not if
  2. default: cases in switch statements are bad

My reason for this is that switch statements without default: cases make the intent of the code explicit; we can be sure when reading code that the developer has properly considered every case.

As an extra bonus, you'll now get a compile-time error if more cases are ever added to the enumeration. This isn't as uncommon as you might think - Apple added a new case .provisional to the UNAuthorizationStatus enumeration in the iOS 12 SDK.

It's too early to have seen any real benefits from doing this (other than annoyed colleagues after I've reviewed their pull requests) but I'm sure we'll be glad of it sometime in the future.

Exceptions to these rules

In unit-test code, I wouldn't insist on switching over an enumeration. It's quite valid to do this when asserting the result of some operation:

guard case let MyEnumeration.firstCase(myValue) = someResult else {
	XCTFail("Expected a 'firstCase' but got \(someResult) instead")
	return
}

XCTAssertEqual(myValue, "expected value")

Extra bonus half-rule with no explanation

An enumeration with more than ten values is a code-smell.

Tagged with:

First published 3 November 2018