Schreibe und akzeptiere nur lesbaren Code!

Artikel#: 00055

Datum: 2021-03-04

Autor: Radim

Wenn du ein Programm schreibst, musst du sicherstellen, dass es korrekt geschrieben ist, damit es funktioniert...
Das Programm muss jedoch auch so geschrieben sein, dass es von anderen Teammitgliedern oder von jemandem gelesen werden kann, der das Programm "in einem Jahr" ändern muss.
Wenn ein Programm ein Problem oder einen Fehler aufweist, ist es einfacher, die Ursache des Problems zu ermitteln, wenn das Programm klar und lesbar geschrieben ist.

Im Allgemeinen verbringen wir mehr Zeit damit, ein Programm zu lesen als es zu schreiben.
Das Schreiben von verständlichem Code erleichtert es jedem, den Code durchzugehen und zu überarbeiten.
Der Code sollte so geschrieben sein, dass alle Programmierer ihn verstehen können.

Gut geschriebener Quellcode ist an sich die detaillierteste Dokumentation eines Programms.
Alles, was das Programm wirklich tut, wird hier genau beschrieben.
Du musst dann nur noch dokumentieren, was die einzelnen Funktionen und Modulen tun, da die Art und Weise, wie sie es tun, im Quellcode enthalten ist.

Es ist notwendig, den Code so zu schreiben, dass er jahrzehntelang verwendet und gewartet werden kann.
Man weiss nie, ob das am Ende nicht wirklich passieren wird.

Die wiederholte Verwendung des Codes und die gemeinsame Nutzung zwischen Entwicklern kann die Produktivität des Teams erheblich steigern.
Niemand wird unlesbaren Code in sein Modul aufnehmen.
Im Gegenteil, lesbarer und klarer Code wird jedem gefallen, da er Arbeit spart und man etwas aus dem Code lernen kann.

Es ist wichtig, den Code bereits von Anfang an gut lesbar zu schreiben.
Denkt nicht, dass ihr, wenn alles erledigt ist, die Zeit und die Lust haben werdet, den unlesbaren Code besser lesbar umzuschreiben.

Die Person, die das Programm übernimmt, sollte die Qualität des Quellcodes bewerten und den unlesbaren Code als Fehler beanstanden und eine Korrektur verlangen.
Lesbarer Code erhöht die Entwicklungsgeschwindigkeit und die Qualität der erstellten Anwendung.

© Radim-Automation, 2020–2025. Alle Rechte vorbehalten.
Die Verbreitung dieses Artikels ist mit Angabe der Quelle (Link zur Originalseite) ausdrücklich gestattet.

Verwandte vorherige Artikel:

• Wer weiss es?
• Ernenne einen Vertreter!
• Schreibe deine Best Practices und Prozesse auf!
• Willst du damit wirklich beginnen?
• Speichere Email-Nachrichten im Projektordner!
• Ich sehe was, was du nicht siehst
• Mehr als nur starten und stoppen
• Sicherheit zuerst!
• Mach die richtigen Dinge und mach sie richtig!
• Mach es nicht schlimmer!
• Schreibe ein Projekttagebuch!
• Behaltet die Antworten auf die Frage "Warum"
• Alles ist schwierig, bis es einfach wird
• Führt die Terminologie ein und vereinheitlicht sie!
• Verwirkliche jede gute Idee so schnell wie möglich!
• Enttäuscht euren Kunden nicht!
• Weise Aufgaben effizient zu!
• Kommunikationsfähigkeiten sind äusserst wichtig
• Ersetze Mitarbeiter nicht in der Mitte des Projekts!
• Entwickle Verantwortungsbewusstsein!
• Rekrutiere und behalte die besten Mitarbeiter!
• Erledige die Dinge mit einem kleinen, motivierten Team!
• Konzentriere dich auf das Ziel!
• 9 Frauen können ein Baby nicht in einem Monat zur Welt bringen
• Schärfe deine Axt, bevor du beginnst zu fällen!
• Verstehen - Einverstanden sein - Identifiziert sein - Glauben
• Verstecke kein Problem!
• Überprüfe das Ergebnis!
• Halte es einfach!
• Verlass kein Arbeitspaket halbfertig!
• Entwicklung ist Evolution
• Vernachlässige und überspringe keinen Schritt!
• Transparenz und Zuverlässigkeit

Verwandte nächste Artikel:

• Verwende einen nützlichen Styleguide!
• Warum scheitern Automatisierungsprojekte?
• Projektleiter
• Lerne von deiner Reise!
• Modulare Softwarearchitektur
• Abkürzungen
• Maschinenmodularisierung
• Erkenntnisse aus einem abgeschlossenen Projekt sind unbezahlbar
• Variablennamen
• Wahl der Programmiersprache
• Dokumentationsprobleme
• Ereignislogger als allererste im Programm implementierte Funktion
• Diagnosetools
• Mein Chef war ein Held
• Versionskontrollsystem
• Pflege Ordnung im Programmkode
• Codeformatierung
• Traum von einem plattformunabhängigen SPS-Programm
• Halte alles, was du brauchst, zusammen
• Ein unersetzbarer Mitarbeiter
• Versteckte Gefahren bei der Inbetriebnahme
• Die falsche Illusion des schnellen Fortschritts

Kommentar#: 00001

Datum: 2021-03-04

Benutzer: Radim

Wir können den Code auch wie eine Investition verstehen. Deshalb sollen wir den Code wiederverwendbar machen.

Kommentar#: 00002

Datum: 2021-03-04

Benutzer: Radim

Wenn der Code nicht kommentiert und unverständlich ist, ist jede Änderung äusserst schwierig.
Unsachgemässe Codeänderungen können an anderer Stelle eine Reihe von Fehlern verursachen und das Programm nicht nachhaltig machen.
Selbst ein gut geschriebenes Programm kann im Laufe der Zeit einen solchen Zustand erreichen, wenn es mehrfach "verbessert" und erweitert wurde.

Kommentar#: 00003

Datum: 2021-07-01

Benutzer: Radim

Wenn Personen unterschiedlicher Nationalität am Programm arbeiten, darf im Programm nur eine vereinbarte Sprache (ohne Zweifel, dass Englisch die beste Wahl ist) für Objektnamen und Programmkommentare verwendet werden.
Auch wenn ein vorläufiges Programm geschrieben werden soll, müssen Konventionen eingehalten werden.
Es ist jederzeit einfacher, einige Teile des vorläufigen Programms in das endgültige Programm zu kopieren, wenn die Konventionen immer befolgt wurden.

Kommentar#: 00004

Datum: 2021-07-19

Benutzer: Radim

Wenn wir bereits geschriebenen Code wiederverwenden können, wird dies weniger Aufwand und Zeit in Anspruch nehmen. Aber Vorsicht! Wenn dieser Code schlecht ist (ein Fehler darin ist oder er unleserlich ist), verteilen wir ihn auch schnell an viele Anwendungen, indem wir ihn wiederverwenden. Dies führt zu zahlreichen Problemen, die alle sehr mühsam zu beheben sind.

Kommentar#: 00005

Datum: 2021-09-10

Benutzer: Radim

"Programmierer verwenden gerne Tricks, sie fühlen sich grossartig, als würden sie ein schwieriges Rätsel lösen. Und sie gewinnen den Respekt ihrer Kollegen. Die Gefahren von Tricks sind ihnen jedoch meist nicht bewusst. Tricks sind wie ein Sprengstoff in der Konstruktion. Manchmal ist es ratsam, es zu verwenden, wenn man weiss, wie man es benutzt, aber es ist ein sehr gefährliches Werkzeug, das bei unsachgemässer Handhabung viel Schaden anrichten kann.
Es ist daher immer wichtig abzuwägen, ob es wirklich Sinn macht, den Trick anzuwenden.
Es muss auch berücksichtigt werden, dass Codeleser die Tricks nicht verstehen und wir sie daher sehr ausführlich kommentieren müssen."
Übersetzt von:
- Petr Paleta. Computer Press (2003). Co programátory ve škole neučí.

Kommentar#: 00006

Datum: 2021-10-28

Benutzer: Radim

"Meistens machen wir ein Programm komplizierter, wenn wir versuchen, etwas zu reparieren, indem wir gewaltsam weiteren Code hinzufügen."
- https://bonsai-development.cz/clanek/jak-na-jednoduchy-kod

Kommentar#: 00007

Datum: 2021-10-31

Benutzer: Radim

"Denken Sie darüber nach, Ihre Programme so zu gestalten, dass es für diejenigen einfacher ist, die sie nach Ihnen pflegen."
- https://norvig.com/21-days.html

Kommentar#: 00008

Datum: 2022-09-13

Benutzer: Radim

"Gute Software zu schreiben erfordert die Bereitschaft, weiter an einem Problem zu arbeiten, Code im Laufe der Zeit lesbarer, effizienter und weniger fehleranfällig zu machen, indem man auf Feedback reagiert und gründlich über Probleme nachdenkt (manchmal ist das beste Werkzeug ein Bleistift und Papier zum Aufschreiben Ihre Gedanken). Erwarten Sie nicht, dass Sie beim ersten Mal alles richtig machen!"
- https://towardsdatascience.com/notes-on-software-construction-from-code-complete-8d2a8a959c69

Kommentar#: 00009

Datum: 2022-11-14

Benutzer: Radim

"Experten für Softwareanalyse sind sich einig, dass der Codequalität heutzutage ein bemerkenswertes Wachstum an Aufmerksamkeit und Nachfrage zuteil wird. Sie bestätigen, dass die kontinuierliche Weiterentwicklung eines Softwaresystems den Quellcode nach zahlreichen Updates erheblich komplizierter macht. Daher muss das Team den Code kontinuierlich analysieren, um die Code-Basis in einem gut wartbaren Zustand zu halten, um ungedeckte technische Schulden, Systemabstürze und teure Fixes zu vermeiden."
Übersetzt von:
- https://stackify.com/software-testing-tips/

Kommentar#: 00010

Datum: 2023-06-08

Benutzer: Radim

"Investitionen in gute Codequalität und gute Architektur sind nachhaltige Investitionen. Über 80% der Entwicklungs-Arbeiten sind Wartungsarbeiten sowie Änderungen an bestehendem Code. Prof. Niklaus Wirth meinte einmal, dass SW nicht für den Compiler geschrieben wird, sondern für Menschen die den Code warten müssen. Stellt sich die Frage nach „quick and dirty“, ist die Tragbarkeit der «technischen Schuld» mit zu berücksichtigen, denn irgendwann wird die Schuld untragbar oder so gross, dass ein «Neubeginn» billiger wird. Versicherungstechnisch spricht man hier von einem «Total-Schaden». Oft wird bei «quick and dirty Lösungen» immer wieder im gleiche Stil weiter «gewurstelt». Neben bestehenden schlechten Codestellen fallen weitere «Spaghetti – Zeilen» nicht mehr auf, ein Freipass…

So beginnt ein Teufelskreis, denn mit der wachsenden «technischen Schuld», verlangsamt sich –wegen unlesbarem und schlechtem Code – auch die Entwicklungsgeschwindigkeit. Dies verzögert das Fertigstellen neuer Features und das Projekt muss mit explosiv steigenden Opportunitätskosten leben."
- https://blog.noser.com/kennen-sie-ihre-technische-schuld-wir-unterstuetzen-sie-bei-der-rueckzahlung/

Kommentar#: 00011

Datum: 2023-09-27

Benutzer: Radim

"Indem wir das Design des Codes kontinuierlich verbessern, machen wir es immer einfacher, damit zu arbeiten.
Dies steht in krassem Gegensatz zu dem, was normalerweise geschieht: wenig Refactoring und viel Aufmerksamkeit, um schnell neue Funktionen hinzuzufügen.
Wenn man sich die hygienische Angewohnheit angewöhnt, kontinuierlich zu refaktorisieren, wird man feststellen, dass es einfacher ist, den Code zu erweitern und zu pflegen."

Übersetzt von:
- Joshua Kerievsky. Addison-Wesley (2004). Refactoring to Patterns.

Kommentar#: 00013

Datum: 2024-02-22

Benutzer: Radim

Ist Ihre Muttersprache nicht Englisch und arbeiten Sie in einem internationalen Team? Haben Sie sich im Team auf Englisch als Projektsprache geeinigt? Dann bitte:

1. Installieren und benutzen Sie alle Projektwerkzeuge auf Englisch.
2. Verwenden Sie englische Hilfedateien für die Werkzeuge.
3. Schreiben Sie englische Variablennamen und Kommentare in den Code.

Diese Regeln erleichtern die Zusammenarbeit zwischen den Teammitgliedern, die Dokumentation und die Supportaufgaben. Denn die Leute werden die gleichen Begriffe verwenden.

Sind Sie mit diesen Regeln einverstanden?
Würden Sie noch etwas hinzufügen?

Kommentar#: 00014

Datum: 2024-03-25

Benutzer: Radim

Es gibt einige Vorteile des alphabetischen Sortierens von Variablen innerhalb eines Deklarationsblocks:

1. Einfacheres Suchen: Wenn Variablen alphabetisch sortiert sind, ist es einfacher, eine bestimmte Variable zu finden, weil du weisst, dass sie an einer bestimmten Stelle in alphabetischer Reihenfolge stehen wird.

2. Schnellere Aktualisierungen und Modifikationen: Beim Aktualisieren oder Modifizieren vorhandener Variablen ist es einfacher, die entsprechende Variable zu finden, wenn die Variablen alphabetisch sortiert sind.

3. Einfacheres Erstellen neuer Variablen: Beim Erstellen neuer Variablen kannst du einfacher einen geeigneten Namen auswählen, wenn du einen Überblick über alle vorhandenen Variablen und ihre alphabetische Reihenfolge hast.

4. Code-Klarheit und Wartung: Das alphabetische Sortieren von Variablen trägt zur Klarheit des Codes bei und erleichtert dessen Wartung, weil der Programmierer weiss, wo er nach einer bestimmten Variable suchen muss.

Es ist jedoch wichtig, sich an konsistente Regeln für das Benennen von Variablen zu halten.

Kommentar#: 00015

Datum: 2024-03-25

Benutzer: Radim

Entfernen Sie den "Ballast" aus dem Programm!

Bauen Sie nur die Dinge in das Programm ein, die wirklich benötigt werden. Unnötige Teile des Codes im Programm werden veraltet, ungetestet, werfen unnötige Fragen auf und sind eine Quelle der Unklarheit.

Manchmal ist es eine gute Idee, mehr als einen Weg in der Praxis auszuprobieren, um herauszufinden, welcher Weg der beste ist. Sobald wir uns jedoch für einen bestimmten Ansatz entschieden haben, ist es wichtig, unsere Methoden zu konsolidieren und die überholten zu entfernen. Indem wir "Ballast" aus dem Programm entfernen, beseitigen wir potenzielle Quellen der Verwirrung und verbessern die Gesamtqualität des Codes.

Kommentar#: 00016

Datum: 2024-04-10

Benutzer: Radim

"Codekonventionen sind für Programmierer aus mehreren Gründen wichtig:

• 40%-80% der Lebenszeitkosten einer Software entfallen auf die Wartung.

• Kaum eine Software wird während ihrer gesamten Lebensdauer vom ursprünglichen Autor gewartet.

• Codekonventionen verbessern die Lesbarkeit der Software und ermöglichen es den Ingenieuren, neuen Code schneller und gründlicher zu verstehen.

• Wenn Sie Ihren Quellcode als Produkt ausliefern, müssen Sie dafür sorgen, dass er genauso gut verpackt und sauber ist wie jedes andere Produkt, das Sie erstellen."

- https://en.wikipedia.org/wiki/Coding_conventions
(übersetzt aus dem Englischen)