Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Lesedauer 4 Min.

4 Gründe auf Schleifen zu verzichten

Entwickler Marco Emrich vom IT-Beratungsunternehmen Codecentric erklärt die Tücken von Programmschleifen und nennt ein paar Möglichkeiten, wie man ohne sie auskommen kann.
Programmschleifen sind eines der ersten Konstrukte sind, die angehende Programmierer lernen und kaum ein Programm kommt ohne sie aus. Trotzdem können gerade die Schleifen viele potenzielle Probleme aufwerfen. Dem stimmt auch Marco Emrich vom IT-Beratungsunternehmen Codecentric zu, der auf der diesjährigen OSCON-Konferenz sagte: "Wenn du immer noch Loops schreibst, bist du kein schlechter Mensch. Denke nur darüber nach, ob du Schleifen schreiben musst oder ob es eine bessere Alternative gibt".Bevor Sie also mit der Programmierung der nächsten do/while-Schleife beginnen, sollten Sie sich die potenziellen Probleme ansehen, die Autoren von Schleifen haben:1. Eine Durchlauf fehlt: Hier denkt der Programmierer, dass er eine Schleife hat, die etwas 10-mal ausführt, obwohl sie tatsächlich nur neun mal durchläuft. Oder 11-mal. Denken Sie an "<=" (kleiner oder gleich) anstelle von "<" (kleiner). Es ist ein subtiler, aber häufiger Fehler der Entwickler dazu verführt "Voodoo" mit ihrem Code machen, indem sie die Parameter leicht ändern, um die richtige Antwort zu erhalten, ohne die eigentliche Logik, die den Code antreibt, vollständig zu verstehen.2. Endlosschleifen: Wenn ein Programm stecken bleibt und der Benutzer nur das Schließen der Anwendung erzwingen kann, ist der wahrscheinliche Täter eine Endlosschleife, eine Schleife, die nie endet. Wie das Zählproblem können diese Fehler subtil sein. Emrich nannte das Beispiel eines falschen Semikolons, das nach einer "while"-Anweisung platziert wurde, was dazu führen kann, dass ein Programm nie in den Ausgangszustand der Schleife gelangt.3. Zustandsabhängigkeit: Im Gegensatz zu den anfänglichen Wahrnehmungen sind Schleifen alle im Zustand gebunden. "Schleifen sind wirklich zustandsorientiert. Ich würde sagen, dass Schleifen geradezu verseucht mit Zuständen (state infested) sind", sagte Emrich. Dies ist problematisch, wenn es um das Debuggen von Software geht, da der Code, den Sie zur Laufzeit haben, nicht der gleiche ist wie das, was Sie in Ihrem Editor sehen.4. Versteckte Absicht: In vielen Fällen kann ein Schleifenkonstrukt verdecken, was es zu tun gedenkt. Das führt dazu, dass der Programmierer (oder ein anderer Programmierer) zurückkehren und seine Absicht rückentwickeln muss. "Ich kann diese Zeit mit wichtigeren Themen verbringen", sagte Emrich.Welche Alternativen gibt es zur guten altmodischen Iteration? Eine davon ist die Rekursion. Nehmen Sie zum Beispiel den Quicksort-Algorithmus, der Zahlen nicht durch eine Schleife sortiert, sondern zwei Zahlen wiederholt vergleicht und ein Array Element für Element durcharbeitet. Natürlich sind funktionale Sprachen wie Haskell gut in der Rekursion, aber auch generalisierte Sprachen wie JavaScript bieten funktionale Bibliotheken.Rekursion ist einfacher zu verstehen, und mit ein paar einfachen Schritten können Optimierungen genauso schnell sein wie Schleifen. Allerdings ist Rekursion nur für eine Teilmenge von Problemen gut ist, wie zum Beispiel komplexe Listenoperationen, multidimensionale Probleme und für baumbasierte und grafische Algorithmen.Schauen Sie auch auf Funktionen höherer Ordnung, die das spezifische Problem, das Sie zu lösen versuchen, angehen, und bringen Sie auch ihr eigenes Vokabular mit, um das, was Sie schreiben, für andere oder für sich selbst zu einem späteren Zeitpunkt verständlich zu machen.Dies kümmert sich um das Problem der "versteckten Absicht": Also beginnt das Programm viel absichtsvoller zu werden. Eine Map-Funktion wendet eine bestimmte Funktion (zum Beispiel das Quadrieren einer Zahl) auf alle Elemente eines Arrays an. Eine Mapping-Funktion sieht anfangs etwas beängstigend aus, weil man die Liste in einen Stream konvertieren muss, aber das ist nicht so schlimm, weil man es am Anfang macht und dann so viele Transformationen hat, wie man will, und am Ende sammelt man alles wieder in ein Array", sagte Emrich. Überprüfen Sie Ihre bevorzugte Programmiersprache auf Bibliotheken, welche die Notwendigkeit von Schleifen vermeiden.Wann sollten Sie dann Schleifen verwenden? Wenn die Leistung kritisch ist, können sie Leistungsvorteile bieten. Selbst dann ist es wichtig, sich anzusehen, wo der Performance-Engpass liegt, und das ist selten bei der Schleife selbst. "Sollten Schleifen tatsächlich sterben? Die Antwort ist: Es kommt darauf an. Das ist die einzige Antwort, die man je in der Softwareentwicklung erhält", sagte Emrich.www.codecentric.de/
Miscellaneous

Neueste Beiträge

Übersehen seit .NET 8: TimeProvider für testbare Zeit
Seit .NET 8 gibt es TimeProvider als offizielle Zeit-Abstraktion. Doch noch zweieinhalb Jahre später ist sie in vielen Projekten unbekannt.
6 Minuten
1. Jul 2026
Design mit KI - UX goes Dev, Teil 2
Wie die Integration künstlicher Intelligenz in Designwerkzeuge die Art und Weise verändert, in der digitale Benutzeroberflächen entstehen.
6 Minuten
2. Jul 2026
KI: SQL Server versus Anwendungscode - SQL Server 2025 und Microsoft Azure AI, Teil 2
Wer SQL Server und Anwendungscode bewusst trennt, erhält eine Architektur, die sowohl performant als auch wartbar ist und sich langfristig stabil betreiben lässt.
6 Minuten

Das könnte Dich auch interessieren

SOLID SAM
Drei einfache, aber fundamentale Regeln bilden den Einstieg in die Composite-Components-Architektur.
6 Minuten
27. Mai 2026
Moderne Softwarearchitektur - Funktionale Architektur mit F#
Das Konzept der funktionalen Architektur mit F# ist in der Praxis nicht so kompliziert, wie es auf den ersten Blick erscheint.
13 Minuten
15. Apr 2024
Was sind Komponenten? - Composite Components 2.0, Teil 8
Softwareprojekte wie mit Lego bauen – dazu muss der Architekt in Komponenten denken.
6 Minuten
15. Jun 2020
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige