One of my goals for May 2018 was to finally read The Pragmatic Programmer. I haven't succeeded yet, that's why this year, June was May, Extended Edition and July is June, Extended Edition.

A few years ago, a dear friend of mine rec­om­mend­ed reading this book to me and I should have listened to him. It is so in­ter­est­ing to read, I've learned a lot of things and I'm barely halfway through. What I like about this book is that it encourages you to think about your work and how you achieve it. It shows you good practices without being arrogant.

As I'm reading this book quite in­ten­sive­ly, I take a lot of notes. If you're interested to read them, I'd be more than happy to publish them in another blogpost. Just let me know. At the moment, they're written down in my old-fashioned notebook.

In "The Pragmatic Pro­gram­mer", there are several advices. Number 31 of them is:

Design by Contract.

One of several things written down in a contract are pre­con­di­tions. They're basically re­quire­ments or conditions, that one party must ensure to be true, before the other party can start to fulfill its part of the contract. It is to be defined in the contract, which party must ensure, that these re­quire­ments are met.

I am an iOS developer for a living. A few months ago, a former colleague of mine showed me assert, assertionFailure, precondition and preconditionFailure.

The main difference — he explained it to me at least this way — was that assert(false) and assertionFailure let the app crash only in debug-builds, while a preconditionFailure leads to a crash in release-builds as well

When I read about pre­con­di­tions in "The Pragmatic Pro­gram­mer", I felt like being reminded about this con­ver­sa­tion between my coworker and me. So I read Apple's doc­u­men­ta­tion of preconditionFailure again. It says:

Indicates that a pre­con­di­tion was violated.

Use this function to stop the program when control flow can only reach the call if your API was improperly used.

Next, I wanted to know, if Swift has some kind of Design by Contract support, but the mighty Internet says no:

The meaning of Apple's precondition and preconditionFailure differs slightly from DbC, just like the way they want me to use them:

The global functions assert, assertionFailure, precondition and preconditionFailure are designed to be sprinkled liberally throughout code without impacting release build per­for­mance. — Source

So, yeah, as a conclusion one could say, that precondition the DbC-way seems to be different from swifty precondition.

Another thing I'd like to mention is, that I'd like to write more blogposts like this: somehow pro­gram­ming-related, short articles in English. I'm not entirely sure about the format: Should I just use this — German — blog? Should I start another one?

#dbhackathon » « Angela Merkel ist Hitlers Tochter