Swift-Tutorial Teil 5: Das geht noch besser

Hallo zusammen! In diesem Teil unseres Swift Tutorials werden wir eine Menge neuer Sprachkonstrukte kennenlernen, die unabdinglich sind, damit guter Source Code überhaupt entstehen kann. Ja genau, guter Sourcecode. Denn bekanntlich führen viele Wege nach Rom und darunter verstecken sich einige, die man lieber nicht gehen sollte. Aber genug der Metaphern. Richten wir unsere Aufmerksamkeit auf die Frage: Was macht Source Code zu gutem Source Code?

Die 3 wichtigsten Tipps für sauberen Source Code

Beginnen wir mit drei Kriterien:

1. Don’t ignore warnings: Moderne Entwicklungsumgebungen, wie Xcode, geben Programmierern Hinweise auf problematischen Source Code, der zur Laufzeit zu Fehlern führen könnte. Diese Warnungen zu ignorieren ist schlicht fahrlässig. Das ist so, als würde man die leuchtende Ölstandsanzeige im Auto sehen und dennoch entspannt weiterfahren. Also, auch wenn es lästig ist, Warnungen haben ihren Sinn und sollten immer beachtet werden.
2. Don’t repeat yourself (Dry): Wiederhole dich nicht selbst, bedeutet schlicht, dass gleicher oder fast gleicher Source Code gemieden werden sollte. Wenn in einem Programm irgendeine Tätigkeit an verschiedenen Stellen ausgeführt werden muss, sollte der entsprechende Source Code nur ein mal vorhanden sein. Etwas technischer ausgedrückt: Vermeide Redundanz in deinem Source Code.
3. Lesbarkeit: Ja es ist richtig: Ein Programm wird von einer Maschine ausgeführt. Was hilft es da, wenn ich ausschweifend lange Variablennamen benutze und mir auch sonst sehr viel Mühe gebe, den Source Code lesbar zu gestalten? Ich weiß doch, was ich mit allem meine und der Rechner kommt eh damit klar. Nun das stimmt nur, wenn du ein perfektes Gedächtnis hast. Und glaub mir, das hat niemand. Es wird der Tag kommen, an dem du einen Fehler beseitigen willst oder eine Erweiterung programmieren möchtest. Dann ist es wichtig, den alten, schlecht lesbaren Source Code zu verstehen. Oder denk an die absolut realistische Situation, dass mehrere Programmierer am selben Source Code arbeiten müssen. Denk einfach daran: Du schreibst nicht für dich, sondern für denjenigen, der nach dir den Source Code lesen muss.

Natürlich gibt es noch mehr Kriterien oder Prinzipien, nach denen man sich richten sollte, wenn man programmiert. Ich werde im Laufe der nächsten Blog-Beiträge im Rahmen der Swift Tutorial Reihe weitere vorstellen. Ich habe mich entschlossen auf diese Punkte einzugehen, weil ich der Meinung bin, dass man einen guten Programmierstil nicht früh genug lernen kann.

Dir Swift beizubringen und dich dann damit allein zu lassen, entspricht nicht meiner Vorstellung eines Tutorials. Deswegen werden wir uns in diesem Teil damit beschäftigen, die obigen Kriterien auf den aktuellen Stand unseres Source Codes anzuwenden.

Optimierung unseres Swift Tutorial Source Codes

Gut, dann schauen wir uns doch mal den Source Code an, den wir am Ende in Swift Tutorial Teil 4 geschrieben haben:

import Foundation

func compute(expression : String) -> Double? {
    if let operatorIndex  = getOperatorIndex(expression) {
        let operatorSymbol = expression[operatorIndex]
        let leftUntrimmed  = expression[..<operatorIndex]
        let leftStr        = leftUntrimmed.trimmingCharacters(in: CharacterSet.whitespacesAndNewlines)
        let left           = Double(leftStr)!
        let rightUntrimmed = expression[expression.index(after: operatorIndex)..<expression.endIndex]
        let rightStr       = rightUntrimmed.trimmingCharacters(in: CharacterSet.whitespacesAndNewlines)
        let right          = Double(rightStr)!

        if (operatorSymbol == "+") {
            return add(value1: left , value2: right)
        }

        if (operatorSymbol == "-") {
            return subtract(value1: left , value2: right)
        }

        if (operatorSymbol == "*") {
            return multiply(value1: left , value2: right)
        }

        return divide(value1: left , value2: right)
    }

    return nil
}

func getOperatorIndex(_ expression : String) -> String.Index? {
    var index  = expression.index(of: "+")
    
    if (index == nil) {
        index  = expression.index(of: "-")
        
        if (index == nil) {
            index  = expression.index(of: "*")
            
            if (index == nil) {
                index  = expression.index(of: "/")
            }
        }
    }
    
    return index
}

func add(value1: Double, value2: Double) -> Double {
    return value1 + value2
}

func subtract(value1: Double, value2: Double) -> Double {
    return value1 - value2
}

func multiply(value1: Double, value2: Double) -> Double {
    return value1 * value2
}

func divide(value1: Double, value2: Double) -> Double {
    return value1 / value2
}

let myAddition = "20 + 7"
let mySubtraction = "35 - 8"
let myMultiplication = "13.5 * 2"
let myDivision = "54 / 2"
let myWrongAddition = "20 = 7"

let additionResult = compute(expression: myAddition)
let subtractionResult = compute(expression: mySubtraction)
let multiplicationResult = compute(expression: myMultiplication)
let divisionResult = compute(expression: myDivision)
let wrongAdditionResult = compute(expression: myWrongAddition)

print("Die Summe \(myAddition) ist gleich \(additionResult)")
print("Die Subtraktion \(mySubtraction) ist gleich \(subtractionResult)")
print("Die Multiplikation \(myMultiplication) ist gleich \(multiplicationResult)")
print("Die Subtraktion \(myDivision) ist gleich \(divisionResult)")
print("Die fehlerhafte Summe \(myWrongAddition) ist gleich \(wrongAdditionResult)")

Wir kümmern uns zunächst um die Warnungen, die sich auf die print Anweisungen beziehen. Sie bieten uns zwei mögliche Lösungen an:

1. Use 'String(describing:)' to silence this warning
2. Provide a default value to avoid this warning

Die erste Warnung schlägt vor, den Initializer String(describing:) zu benutzen. Lass uns das einfach versuchen.

print("Die Summe \(myAddition) ist gleich \(String(describing: additionResult))")
print("Die Subtraktion \(mySubtraction) ist gleich \(String(describing: subtractionResult))")
print("Die Multiplikation \(myMultiplication) ist gleich \(String(describing: multiplicationResult))")
print("Die Subtraktion \(myDivision) ist gleich \(String(describing: divisionResult))")
print("Die fehlerhafte Summe \(myWrongAddition) ist gleich \(String(describing: wrongAdditionResult))")

Der Initializer String(describing:) erzeugt eine Zeichenkette (String) für den übergebenen Wert. Wenn der Wert ein "Optional" ist, wird der eingepackte Wert ausgelesen und eine Zeichenkette für ihn erzeugt und zurückgeliefert. Mit dieser Vorgehensweise wird auch für die letzte Konstante wrongAdditionResult, die ja "nil" ist, ein String erzeugt, der den Wert nil besitzt. Das bedeutet, dass der Initializer uns die Arbeit abnimmt, einen Wert auszupacken bzw. zu überprüfen, ob dieser nil ist. Diese Lösung führt eindeutig dazu, dass die Warnungen alle verschwinden. Mal sehen, ob es eine bessere Lösung gibt.

Die zweite Möglichkeit nutzt den sogenannten Nil-Coalescing Operator ??, um in dem Fall, dass der Wert einer der Konstanten nil ist, einen (anderen) Standardwert auszugeben.

if (a != nil) {
    a = a!
}
else {
    a = b
}

let defaultLevel = 27
var userDefinedLevel: Int?   // Deklaration ohne Initialisierung. Ist also nil

var startLevel = userDefinedLevel ?? defaultLevel

Betrachte dazu den folgenden Source Code:

print("Die Summe \(myAddition) ist gleich \(additionResult ?? -9999.0)")
print("Die Subtraktion \(mySubtraction) ist gleich \(subtractionResult ?? -9999.0)")
print("Die Multiplikation \(myMultiplication) ist gleich \(multiplicationResult ?? -9999.0)")
print("Die Subtraktion \(myDivision) ist gleich \(divisionResult ?? -9999.0)")
print("Die fehlerhafte Summe \(myWrongAddition) ist gleich \(wrongAdditionResult ?? -9999.0)")

Du wirst dich sicherlich fragen, warum der Standardwert 9999.0 ist. Wenn man ehrlich ist, muss man darauf antworten: Weil diese Umsetzung schlecht ist. Im Ernst, ich habe sie hier aufgeführt, weil ich dir ein Problem erklären will, und zwar, dass nicht jede Lösung, die Xcode anbietet, in jeder Situation angemessen ist.

In diesem Fall macht ein Standardwert tatsächlich keinen Sinn. Oder kannst du mir sagen, was ein Standardergebnis einer beliebigen Addition, die auch noch fehlerhaft ist, sein kann? Natürlich nicht, und zwar weil es keinen Standardwert für eine Rechnung gibt. Es gibt entweder einen Lösungswert oder der arithmetische Ausdruck war fehlerhaft. Letzterer Fall führt zu nil und nicht zu einem Standardwert.

Obwohl, es gibt eine Ausnahme: Division durch 0. Dieser Fall führt zwar auch nicht zu einem Wert, dennoch sollte eine Unterscheidung zwischen fehlerhafter Eingabe (z.B. ein unerlaubtes Zeichen) und der Division durch 0 gemacht werden.
 

Optional binding in Swift eine Alternative zu printf

Ok, jetzt haben wir beide Möglichkeiten gesehen und festgestellt, dass nur die erste tatsächlich sinnvoll ist. Ich möchte dir in diesem Swift Tutorial aber noch eine weitere Alternative vorstellen. Dazu ersetze ich sowohl die Definitionen der Konstanten als auch die Print-Ausgaben durch folgenden Source Code:

if let additionResult = compute(expression: myAddition) {
    print("Die Summe \(myAddition) ist gleich \(additionResult)")
}

if let subtractionResult = compute(expression: mySubtraction) {
    print("Die Subtraktion \(mySubtraction) ist gleich \(subtractionResult)")
}

if let multiplicationResult = compute(expression: myMultiplication) {
    print("Die Multiplikation \(myMultiplication) ist gleich \(multiplicationResult)")
}

if let divisionResult = compute(expression: myDivision) {
    print("Die Subtraktion \(myDivision) ist gleich \(divisionResult)")
}

if let wrongAdditionResult = compute(expression: myWrongAddition) {
    print("Die fehlerhafte Summe \(myWrongAddition) ist gleich \(wrongAdditionResult)")
}

Betrachte zunächst nur die ersten drei Zeilen. Mithilfe des "Optional Bindings" haben wir folgende drei Dinge erreicht:

1. die Konstante additionResult ist kein Optional mehr. Sie enthält immer den ausgepackten Wert.
2. Dadurch muss im Source Code zwischen den geschweiften Klammern nie der Wert ausgepackt werden, es ist ja schon längst geschehen.
3. Die Konstante additionResult ist nur im Source Code zwischen den geschweiften Klammern bekannt.

Das gleiche gilt analog für die anderen Optional Bindings.

Vielleicht ist dir aufgefallen, dass bei Ausführung des Programms für die fehlerhafte Addition, deren Ergebnis in der Konstante wrongAdditionResult gespeichert ist, keine Ausgabe erfolgt. Das liegt natürlich daran, dass der Funktionsaufruf compute(expression: myWrongAddition) nil zurück liefert.

Wäre doch schön, wenn man diesen Umstand zu den Print-Ausgaben hinzufügen könnte. Nun, nichts einfacher als das. Zu jedem Optional Binding, können wir jetzt komfortabel einen Else-Zweig einfügen. Das sieht für die Konstante wrongAdditionResult dann folgendermaßen aus:

if let wrongAdditionResult = compute(expression: myWrongAddition) {
    print("Die fehlerhafte Summe \(myWrongAddition) ist gleich \(wrongAdditionResult)")
} else {
    print("Die fehlerhafte Summe \(myWrongAddition) hat natürlich kein Ergebnis.")
}

Betrachten wir als nächstes die Funktion getOperatorIndex(_ expression : String):

func getOperatorIndex(_ expression : String) -> String.Index? {
    var index = expression.index(of: "+")

    if (index == nil) {
        index = expression.index(of: "-")

        if (index == nil) {
            index = expression.index(of: "*")

            if (index == nil) {
                index = expression.index(of: "/")
            }
        }
    }

    return index
}

Diese Funktion könnte man auch wie folgt schreiben:

func getOperatorIndex(_ expression : String) -> String.Index? {
    if let index = expression.index(of: "+") {
      return index
    }

    if let index = expression.index(of: "-") {
        return index
    }

    if let index = expression.index(of: "*") {
        return index
    }

    if let index = expression.index(of: "/") {
        return index
    }

    return nil
}

Welche der zwei Varianten gefällt dir besser? Mir gefällt die zweite Variante besser. Ich kann sie schlicht besser lesen. Aber ganz ehrlich, das sind Feinheiten. Vielleicht kann man damit argumentieren, dass die erste Variante sich ungünstig verhält, wenn man weitere Operatoren hinzufügt. In diesem Fall würden die Einrückungen irgendwann die Lesbarkeit stören.
 

Ein weiterer Ansatz hin zu sauberem Quellcode

Es gibt noch eine weitere Variante, die meiner Meinung nach echte Vorteile hat und die in diesem Tutorial nicht fehlen darf. Zuvor solltest du dir jedoch zwei Themen durchlesen:

var anArray = Array<Int>()

var anotherArray = [Int]() 

anArray.append(9)
anArray.append(12)
anArray.append(15)

print(anArray)

let weekdays = ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"]
var friends  = ["Frodo", "Sam", "Pipin", "Merry"]

let weekdays : [String] = ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"]
var friends  : [String] = ["Frodo", "Sam", "Pipin", "Merry"]

let theThirdDay = weekdays[2]

friends += ["Bilbo", "Meriadoc", "Gandalf", "Aragorrrn", "Boromir", "Legolas", "Gimli"]

print(friends)

friends[7] = "Aragorn"

print(friends)

friends[0...4] = ["5 Hobbits"]

print(friends)

let hobbits = friends.removeFirst()
print(friends)

let gimli = friends.removeLast()
print(friends)

let gandalf = friends.remove(at: 1)
print(friends)

print(hobbits)
print(gimli)
print(gandalf)

let planets = ["Mercury", "Venus", "Earth", "Mars", "Jupiter", "Saturn", "Uranus", "Neptune"]

for planet in planets {
    print(planet)
}

print("Alle Planetennamen sind ausgegeben worden.")

var planets : Set<String> = ["Mercury", "Venus", "Earth", "Mars", "Jupiter", "Saturn", "Uranus", "Neptune"]

for planet in planets {
    print(planet)
}

print("Alle Planetennamen sind ausgegeben worden.")

let elements = ["Al" : "Aluminium", "H" : "Wasserstoff" , "O" : "Sauerstoff", "Cr" : "Chrom"]

for (kuerzel, name) in elements {
    print("Das Element \(name) hat das Kürzel \(kuerzel)")
}

for index in 1...10 {
    print("\(index) mal 2 ist \(index * 2)")
}

let anfang = 3
let ende   = 7

for index in anfang...ende {
    print("\(index) mal 2 ist \(index * 2)")
}

var ergenis = 1
for _ in 1...10 {
    ergenis += ergenis
}

print("2 hoch 10 = \(ergenis)")

Ein Array ist eine bestimmte Datenstruktur, die zu den so genannten Collections gehört. Eine For-In-Schleife (Flow Control) ist ein Sprachkonstrukt, das uns erlaubt den gleiche Source Code mehrmals hintereinander auszuführen. Lies dir die Passagen durch, dann wird alles klarer.

func getOperatorIndex(_ expression : String) -> String.Index? {
    let validOperators : [Character] = ["+", "-", "*", "/"]
    
    for anOperator in validOperators {
        if let index  = expression.index(of: anOperator) {
            return index
        }
    }
    
    return nil
}

Aber was ist hier der eigentliche Vorteil?

1. Nun, die Funktion wird nicht wachsen, wenn weitere Operatoren hinzugefügt werden. Nur das Array validOperators muss erweitert werden. Es ist also eine minimale Änderung notwendig.
2. Es ist jetzt sogar möglich die Liste der erlaubten Operatoren außerhalb der Funktion zu definieren. Dadurch kann die Liste der Operatoren an anderen Stellen des Source Codes wiederverwendet werden.
3. Die Funktion reduziert sich auf die Tätigkeit, den Index eines beliebigen Operators zu finden, ohne zu wissen, um welchen Operator es sich handelt. Die Funktion ist dadurch einfacher geworden.

Ok, die Definition der erlaubten Operatoren kann also auch außerhalb der Funktion liegen. Dann machen wir das doch:

let validOperators : [Character] = ["+", "-", "*", "/"]

func getOperatorIndex(_ expression : String) -> String.Index? {    
    for anOperator in validOperators {
        if let index  = expression.index(of: anOperator) {
            return index
        }
    }
    
    return nil
}

Als nächstes lass uns die Funktion compute(expression : String) leicht verändern:

import Foundation

func compute(expression : String) -> Double? {
    if let operatorIndex = getOperatorIndex(expression) {
        let operatorSymbol = expression[operatorIndex]
        let leftUntrimmed  = expression[..<operatorIndex]
        let leftStr        = leftUntrimmed.trimmingCharacters(in: CharacterSet.whitespacesAndNewlines)
        let left           = Double(leftStr)!
        let rightUntrimmed = expression[expression.index(after: operatorIndex)..<expression.endIndex]
        let rightStr       = rightUntrimmed.trimmingCharacters(in: CharacterSet.whitespacesAndNewlines)
        let right          = Double(rightStr)!
        
        switch operatorSymbol {
            case "+": return add(value1: left , value2: right)
            case "-": return subtract(value1: left , value2: right)
            case "*": return multiply(value1: left , value2: right)
            case "/": return divide(value1: left , value2: right)
            default:  return nil
        }
    }
    
    return nil
}

Wie Du sicherlich schnell erkennen wirst, habe ich die If-Anweisungen durch eine Switch-Anweisung ersetzt. Diese Variante bringt hier nicht wirklich viele Vorteile. Aber eines tut eine Switch-Anweisung immer: Sie zwingt uns über die erlaubten Alternativen nachzudenken. Und wir haben immer einen Fall für die nicht erlaubten Zeichen. Hier ist es der Fall default.

let dayOfWeek = 2

if (dayOfWeek == 1) {
    print("Montag")
} else if (dayOfWeek == 2) {
    print("Dienstag")
} else if (dayOfWeek == 3) {
    print("Mittwoch")
} else if (dayOfWeek == 4) {
    print("Donnerstag")
} else if (dayOfWeek == 5) {
    print("Freitag")
} else if (dayOfWeek == 6) {
    print("Samstag")
} else if (dayOfWeek == 7) {
    print("Sonntag")
} else {
    print("Die Woche hat nur 7 Tage.")
}

switch dayOfWeek {
case 1 : print("Montag")
case 2 : print("Dienstag")
case 3 : print("Mittwoch")
case 4 : print("Donnerstag")
case 5 : print("Freitag")
case 6 : print("Samstag")
case 7 : print("Sonntag")
default: print("Die Woche hat nur 7 Tage.")
}

Ich denke, das waren fürs Erste genug Verbesserungsvorschläge und dass du mit meinen Tutorials mittlerweile einen guten Einblick in die Programmiersprache Swift bekommen hast. Natürlich gibt es noch viel zu lernen, aber mit dem bisher Besprochenen kannst du schon sehr weit kommen. Im nächsten Teil meiner Tutorial-Reihe werde ich dich in das objekt-orientierte Paradigma einführen. Das hört sich jetzt vielleicht etwas theoretisch an – ich verspreche dir aber, dass es sehr interessant wird. Ok, dann bis zum nächsten Beitrag.