# English version below

---

Hallo,

ich weiß nicht, ob ich irgendwen mit diesem Thema abhole, aber ich möchte trotzdem darüber schreiben.

Es geht um **Design by Contract (DbC)**, auch - laut Wikipedia - als Contract Programming bekannt. Ein Design Pattern, welches manche Sprachen von Haus aus unterstützen, z.B.

- Clojure
- D
- Racket
- Scala

\- einem dabei aber gleich auffällt, dass die wirklichen Big Players (C++, Python, Java(script), C#) nicht vorkommen. Tatsächlich hatte ich eine emotionale, negative Reaktion, als ich erfahren habe, dass DbC aus dem C++20er Standard kurzfristig rausgeflogen ist. Ich hatte mich wirklich auf First Class Contracts gefreut. (Es gibt natürlich einige Libraries, die das nachrüsten, so auch in BOOST oder bei Python eine ganze Stange. Aber das ist eben nicht Dasselbe und bringt meiner Erfahrung nach Einbußen mit sich)

### Was ist DbC?

Contracts sind Verträge auf deutsch. Eine Funktion in einem Programm trifft, auch wenn es nicht immer explizit im Code steht, Annahmen, und zwar über Eingabeparameter (***Preconditions***), Ausgabeparameter/Rückgabewerte (***Postconditions***) und den State außerhalb der Funktion während der Ausführung (***Invariants***). Beispiele dafür sind eine geometrische Funktion, deren Parameter in einem gewissen Bereich liegen oder bestimmten Gesetzen und Abhängigkeiten folgen müssen, oder - simpler - eine Funktion, die verspricht, dass der Zeiger, den sie zurück gibt, niemals *null* ist. Selbst Exception Specifications kann man als Contract Programming interpretieren.

First Class Support von DbC bedeutet nun nichts anderes, als dass die Programmiersprache selber Unterstützung für den Ausdruck solcher Contracts mitbringt, und sich um die Einhaltung derselben kümmert. Man kann ansonsten Contracts als kompliziertere Assertions ansehen und ein (möglicherweise einfacheres) Contract System mit solchen auch behelfsweise implementieren. 


![Design_by_contract.svg.png](https://files.peakd.com/file/peakd-hive/t-nil/Ep7uYgjGaiQQsnhEKqaNRDkH1mCvU6quBQS6tq8vFsyRbXY3z6CSWPr3Yfr1dvLZey2.png)


(Bild schamlos beim gleichlautenden Wikipedia-Artikel geklaut)

Setzt euch mal mit dem "Design Pattern"? "Design Approach"? "Design Principle"? auseinander wenn ihr wollt. Noch eine kleine Anektdote zum Schluss: Bei meiner vorletzten Arbeitsstelle habe ich Contract Programming behelfsmäßig mit diesem (https://www.codeproject.com/Articles/8293/Design-by-Contract-in-C+) Codeschnipsel in C++ eingebaut. Ob und wie gut es funktioniert hat, kann ich leider nicht mehr sagen, da ich kurz danach die Firma verlassen habe und eh nur in einem Unterprojekt damit gearbeitet hatte. Aber da die "Bibliothek" (welche den Namen kaum verdient) immer noch verfügbar und sehr simpel gehalten ist, kann man das Ganze sicher zu Lernzwecken hinzuziehen.

Grüezi

---

# English version

---

Hello,

I don't know if I'm picking anyone up with this topic, but I'd like to write about it anyway.

It's about **Design by Contract (DbC)**, also known - according to Wikipedia - as Contract Programming. A design pattern, which some languages support inherently, e.g.

- Clojure
- D
- racket
- Scala

\- but one notices right away that the real big players (C++, Python, Java(script), C#) do not appear. In fact, I had an emotional, negative reaction when I learned that DbC was kicked out of the C++20 standard on short notice. I was really looking forward to First Class Contracts. (Of course, there are some libraries that retrofit this, like in BOOST or in Python a whole bunch. But it's just not the same and in my experience it comes at a cost)

### What is DbC?

Contracts are contracts in German. A function in a program makes assumptions, even if it's not always explicit in the code, about input parameters (***Preconditions***), output parameters/return values (***Postconditions***) and the state outside the function during execution (***Invariants***). Examples include a geometric function whose parameters must lie in a certain range or follow certain laws and dependencies, or - more simply - a function that promises that the pointer it returns will never be *null*. Even exception specifications can be interpreted as contract programming.

First class support of DbC means nothing else than that the programming language itself provides support for the expression of such contracts, and takes care of their compliance. One can regard otherwise Contracts as more complicated Assertions and implement a (possibly simpler) Contract system with such also provisionally. 


![Design_by_contract.svg.png](https://files.peakd.com/file/peakd-hive/t-nil/Ep7uYgjGaiQQsnhEKqaNRDkH1mCvU6quBQS6tq8vFsyRbXY3z6CSWPr3Yfr1dvLZey2.png)


(Image shamelessly stolen from the Wikipedia article of the same name)

Have a sit down with the "design pattern"? "Design Approach"? "Design Principle"? if you want to. One more little anecdote at the end: At my last but one job I implemented Contract Programming in C++ with this (https://www.codeproject.com/Articles/8293/Design-by-Contract-in-C+) code snippet. If and how well it worked, I can't say anymore, because I left the company shortly after and only worked with it in a subproject anyway. But since the "library" (which hardly deserves the name) is still available and very simple, you can certainly use it for learning purposes.

Grüezi

Translated with www.DeepL.com/Translator (free version)