Criticism targeting MVVM (Model–View–View-Model) from late last year essentially points out it’s not the silver bullet some take it for. Most of the stuff is missing the point. How are you supposed to make sense of it? What’s good advice for your project?
Daniel Steinberg’s presentation “Ready for the Future: Writing Better Swift” teaches us a lot about readable code. He refactors a calculation into many functions with very specific responsibilities. The resulting functions are super slim.
The result is this:
let lastWeeksRevenues = lastWeeksSales
» anArrayOfDailySales
» replaceNagiveSalesWithZeroSales
» calculateRevenuesFromSales
When you read that code it should be very clear what’s going on. The function names communicate their intent.
Now the implementation:
func anArrayOfDailySales(rawSales: AppSales) -> [Int] {
return rawSales.map{$0}
}
func replaceNagiveSalesWithZeroSales(sales: [Int]) -> [Int] {
return sales.map(negativeNumbersToZero)
}
func negativeNumbersToZero(number: Int) -> Int {
return max(0, number)
}
func calculateRevenuesFromSales(sales: [Int]) -> [USDollars] {
return sales.map(revenuesInDollarsForCopiesSold)
}
func revenuesInDollarsForCopiesSold(numberOfCopies: Int) -> USDollars {
return numberOfCopies
» revenuesForCopiesSold
» toTheNearestPenny
}
let unitPrice = 1.99
let sellersPercentage = 0.70
func revenuesForCopiesSold(numberOfCopies: Int) -> USDollars {
return Double(numberOfCopies) * unitPrice * sellersPercentage
}
infix operator » {associativity left}
func »<T, U>(input: T, transform: T -> U) -> U {
return transform(input)
}
Apart from the » operator which merely changes foo.map(bar) to foo » bar, the functions are very small, easy to read. This reminds me of the result of 3/4 of Sandi Metz’s arbitrary rules for writing Ruby code:
Of course the result is a lot of functions for a rather simple algorithm. But it works well because it is easy to read in the long term. Even newcomers can grasp what’s going on without knowing much about the language or typical Cocoa-programmer conventions.
Bonus: you can unit test each function to check if the parts of the overall algorithm works as expected.
Something short and sweet I want to share with you because I love how it reads: restoringSelection is a function that takes a block and performs whatever the block does while restoring the current selection in a table view (here: NSTableView). Here’s the implementation. The resulting code from above reads so much nicer than querying selection() first and restoring it afterwards. It communicates very clearly that some state from before will be preserved (or restored).
At first, this was all there was:
protocol DisplaysDateRange {
func showDateRange(dateRange: DateRangeData)
}
class DateRangeViewController: NSViewController, DisplaysDateRange {
@IBOutlet var dateRangeButton: NSButton!
func showDateRange(dateRange: DateRangeData) {
dateRangeButton.title = dateRange.range
}
}
Then I implemented a sub-view controller and delegated to it, too:
class DateRangePickerController: NSViewController, DisplaysDateRange {
// ...
}
class DateRangeViewController: NSViewController, DisplaysDateRange {
@IBOutlet var dateRangeButton: NSButton!
@IBOutlet var dateRangePickerController: DateRangePickerController!
func showDateRange(dateRange: DateRangeData) {
dateRangeButton.title = dateRange.range
dateRangePickerController.showDateRange(dateRange)
}
}
Then, by habit, I remembered Kent Beck’s advise to keep symmetry high for clean and maintainable code:
class DateRangeButton: NSButton, DisplaysDateRange {
func showDateRange(dateRange: DateRangeData) {
title = dateRange.range
}
}
class DateRangeViewController: NSViewController, DisplaysDateRange {
@IBOutlet var dateRangeButton: DateRangeButton!
@IBOutlet var dateRangePickerController: DateRangePickerController!
func showDateRange(dateRange: DateRangeData) {
dateRangeButton.showDateRange(dateRange)
dateRangePickerController.showDateRange(dateRange)
}
}
Sure, now there’s a subclass of NSButton that doesn’t do much and will not be reused in the app. But the intent of delegating DateRangeData to the sub-components is clearer.
Clean and maintainable code will help you see what’s going on when you read the code. title = dateRange.range doesn’t convey everything showDateRange(dateRange) does.
Integrating new functionality is fun. But revisiting 18-months old code isn’t. Back then I created a protocol InvokesWindows to define methods like -showPreferencesWindow which I imported in the menu bar controller to show the preferences when the user selects a pop-up menu item. But I didn’t actually delegate to any instance of InvokesWindows. I used NSApp. (Insert facepalm here.)
The test project I work on to develop a component of the Word Counter faster sets up a lot of service objects during launch. I shaved off 60 lines of AppDelegate by introducing bootstrapping as a thing to my code. This way you can prepare a list of Bootstrapping components and iterate over them to set up one after another.
So UISplitViewController is the new default for iOS apps. Most iPhones have compact-sized size classes. iPads have regular sized ones. The iPhone 6(s) Plus mixes both. Only horizontally regular-sized environments show both the master and the detail scene (or primary and secondary view controller).
Writing clean code makes your life better in the long term, and I find it’s more fun initially. According to Bernstein, CLEAN is an acronym:
His book “Beyond Legacy Code. Nine Practices to Extend the Life (and Value) of Your Software” seems to be a good read. Not through, yet.1
Affiliate link; I get a small kickback from the vendor if you buy from my link but it won’t cost you anything. ↩
I found a cute info-graphic on how to become an iOS developer by John Kim. This study guide contains a passage with a very interesting distinction between programming and engineering. Thanks to it, I found out a detail about what it means to write “clean code.”
Citing from the graphic:
Programming is like building the bridge. You need to know how to use the tools to get your end result. In this way, you need to know the programming language to build your “bridge”
Software engineering is like knowing how to design a bridge. You need to know the proven industry design rules to make a long lasting and reliable “bridge”. In this way you need to learn software engineering to design great software
Learning the Syntax and grammar of a programming language is pretty straight foward [sic!]
Understanding software engineering is the hard part about becoming an iOS developer
Learn BOTH but focus on Software Engieering [sic!]
Software engineering is about the design principles. It’s the necessary condition to plan the components of object-oriented projects like those for iOS and Mac. It is required to write clean code.
Programming itself is about API knowledge, understanding the language grammar and the like.
Of course we write clean code, but we’re able to write it only because we’re able to make a clean design up in the first place. So there’s not much clean coding, but a lot more clean design.