Dieser Abschnitt ist auch wirklich eine Voraussetzung für die Codierung, wie McConnell betont: „Legen Sie Programmierkonventionen fest, bevor Sie mit der Programmierung beginnen. Es ist fast unmöglich, Code zu ändern, um sie später anzupassen.“Wie am Ende der Codierungskonventionen aufgeführt, gibt es unterschiedliche Konventionen für verschiedene Programmiersprachen, so dass es kontraproduktiv sein kann, die gleichen Konventionen in verschiedenen Sprachen anzuwenden. Es ist wichtig zu beachten, dass es für keine Programmiersprache eine bestimmte Codierungskonvention gibt. Jede Organisation verfügt über einen benutzerdefinierten Codierungsstandard für jede Art von Softwareprojekt. Es ist daher zwingend erforderlich, dass der Programmierer vor Beginn des Softwareprojekts einen bestimmten Satz von Codierungsrichtlinien auswählt oder erstellt. Einige Codierungskonventionen sind generisch und gelten möglicherweise nicht für jedes Softwareprojekt, das mit einer bestimmten Programmiersprache geschrieben wurde.

Die Verwendung von Codierungskonventionen ist besonders wichtig, wenn an einem Projekt mehr als ein Programmierer beteiligt ist (es gab Projekte mit Tausenden von Programmierern). Es ist viel einfacher für einen Programmierer, Code zu lesen, der von jemand anderem geschrieben wurde, wenn der gesamte Code denselben Konventionen folgt.

Für einige Beispiele für schlechte Codierungskonventionen bietet Roedy Green einen langen (ironischen) Artikel darüber, wie man nicht wartbaren Code erzeugt.

CommentingEdit

Aufgrund von Zeitbeschränkungen oder begeisterten Programmierern, die sofortige Ergebnisse für ihren Code wünschen, tritt das Kommentieren von Code oft in den Hintergrund. Programmierer, die als Team arbeiten, fanden es besser, Kommentare zu hinterlassen, da die Codierung normalerweise Zyklen folgt oder mehr als eine Person an einem bestimmten Modul arbeiten kann. Einige Funktionen können jedoch die Kosten für den Wissenstransfer zwischen Entwicklern, die an demselben Modul arbeiten, senken.

In den frühen Tagen des Rechnens bestand eine gängige Praxis darin, eine kurze Beschreibung des Folgenden zu hinterlassen:

1. Name des Moduls
2. Zweck des Moduls
3. Beschreibung des Moduls
4. Ursprünglicher Autor
5. Änderungen
6. Autoren, die Code geändert haben, mit einer Beschreibung, warum er geändert wurde.

Die „Beschreibung des Moduls“ sollte so kurz wie möglich sein, ohne jedoch auf Klarheit und Vollständigkeit zu verzichten.

Die letzten beiden Punkte sind jedoch durch das Aufkommen von Revisionskontrollsystemen weitgehend veraltet. Änderungen und ihre Urheberschaft können zuverlässig verfolgt werden, indem solche Tools verwendet werden, anstatt Kommentare zu verwenden.

Wenn komplizierte Logik verwendet wird, empfiehlt es sich, einen Kommentar „Block“ in der Nähe dieses Teils zu hinterlassen, damit ein anderer Programmierer verstehen kann, was genau passiert.

Unit-Tests können eine weitere Möglichkeit sein, zu zeigen, wie Code verwendet werden soll.

Namenskonventionenbearbeiten

Die Verwendung geeigneter Namenskonventionen wird als gute Praxis angesehen. Manchmal neigen Programmierer dazu, X1, Y1 usw. zu verwenden. als Variablen und vergessen, sie durch sinnvolle zu ersetzen, was zu Verwirrung führt.

Es wird normalerweise als gute Praxis angesehen, beschreibende Namen zu verwenden.

Beispiel: Eine Variable zur Aufnahme des Gewichts als Parameter für einen LKW kann TrkWeight oder TruckWeightKilograms heißen, wobei TruckWeightKilograms die bevorzugte ist, da sie sofort erkennbar ist. Siehe camelCase-Benennung von Variablen.

Keep the code simpleEdit

Der Code, den ein Programmierer schreibt, sollte einfach sein. Komplizierte Logik zum Erreichen einer einfachen Sache sollte auf ein Minimum beschränkt werden, da der Code in Zukunft möglicherweise von einem anderen Programmierer geändert wird. Die Logik, die ein Programmierer implementiert, macht für einen anderen möglicherweise keinen Sinn. Halten Sie den Code also immer so einfach wie möglich.

Betrachten Sie beispielsweise diese äquivalenten Zeilen C-Code:

if (hours < 24 && minutes < 60 && seconds < 60){ return true;}else{ return false;}

und

if (hours < 24 && minutes < 60 && seconds < 60) return true;else return false;

und

return hours < 24 && minutes < 60 && seconds < 60;

Der 1. Ansatz , die viel häufiger verwendet wird, ist erheblich größer als die 3. Insbesondere verbraucht es 5 mal mehr vertikalen Bildschirmraum (Zeilen) und 97 Zeichen gegenüber 52 (obwohl Bearbeitungswerkzeuge den Unterschied in der tatsächlichen Eingabe verringern können). Es ist jedoch fraglich, was „einfacher“ ist. Der erste hat ein explizites if / then else , mit einem expliziten Rückgabewert, der offensichtlich mit jedem verbunden ist; Selbst ein unerfahrener Programmierer sollte keine Schwierigkeiten haben, es zu verstehen. Die 2. verwirft lediglich die Klammern und halbiert die „vertikale“ Größe mit geringer Änderung der konzeptionellen Komplexität. In den meisten Sprachen könnten die „return“ -Anweisungen auch an die vorherigen Zeilen angehängt werden, wodurch die „vertikale“ Größe auf nur eine weitere Zeile in der 3. Form gebracht wird.

Die dritte Form minimiert offensichtlich die Größe, kann aber die Komplexität erhöhen: Es lässt die Werte „true“ und „false“ implizit und vermischt die Begriffe „condition“ und „return value“. Es ist wahrscheinlich für die meisten Programmierer offensichtlich, aber ein Anfänger versteht möglicherweise nicht sofort, dass das Ergebnis der Auswertung einer Bedingung tatsächlich ein Wert (vom Typ Boolean oder dessen Äquivalent in einer beliebigen Sprache) ist und daher manipuliert oder zurückgegeben werden kann. In realistischeren Beispielen könnte das 3. Formular Probleme aufgrund der Priorität des Operators haben und möglicherweise einen unerwarteten Typ zurückgeben, bei dem die vorherigen Formulare in einigen Sprachen einen Fehler melden würden. Daher ist „Einfachheit“ nicht nur eine Frage der Länge, sondern der logischen und konzeptionellen Struktur; Code kürzer zu machen, kann ihn weniger oder komplexer machen.

Bei großen, langlebigen Programmen könnte die Verwendung ausführlicher Alternativen zum Aufblähen beitragen.

Durch die Kompaktheit können Programmierer mehr Code pro Seite anzeigen, wodurch Bildlaufgesten und Tastenanschläge reduziert werden. Wenn man bedenkt, wie oft Code während des Schreibens und Wartens angezeigt wird, kann dies zu erheblichen Einsparungen bei den Tastatureingaben des Programmierers während der Lebensdauer des Codes führen. Dies mag für einen Schüler, der zum ersten Mal programmieren lernt, nicht von Bedeutung sein, aber bei der Erstellung und Pflege großer Programme ermöglicht die Reduzierung der Anzahl der Codezeilen, dass mehr Code auf den Bildschirm passt, eine geringfügige Codevereinfachung kann die Produktivität verbessern und auch die Belastung von Fingern, Handgelenken und Augen verringern, die häufige medizinische Probleme sind, unter denen Produktionscodierer und Informationsarbeiter leiden.

Terser Coding beschleunigt die Kompilierung sehr wenig, da weniger Symbole verarbeitet werden müssen. Darüber hinaus kann der 3. Ansatz einen einfacheren Vergleich ähnlicher Codezeilen ermöglichen, insbesondere wenn viele solcher Konstrukte gleichzeitig auf einem Bildschirm angezeigt werden können.

Schließlich können sehr knappe Layouts moderne Breitbild-Computerdisplays je nach Monitorlayout und -einrichtung besser nutzen. In der Vergangenheit waren Bildschirme auf 40 oder 80 Zeichen beschränkt (solche Grenzen entstanden viel früher: Manuskripte, gedruckte Bücher und sogar Schriftrollen verwenden seit Jahrtausenden recht kurze Zeilen (siehe zum Beispiel Gutenberg-Bibel)). Moderne Bildschirme können problemlos 200 oder mehr Zeichen anzeigen, was extrem lange Zeilen ermöglicht. Die meisten modernen Codierungsstile und -standards nehmen nicht die gesamte Breite ein. Wenn also ein Fenster so breit wie der Bildschirm verwendet wird, wird viel verfügbarer Platz verschwendet. Andererseits liegt bei mehreren Fenstern oder bei Verwendung einer IDE oder eines anderen Tools mit verschiedenen Informationen in Seitenbereichen die verfügbare Breite für Code in dem Bereich, der von früheren Systemen bekannt ist.

Es ist auch erwähnenswert, dass das menschliche visuelle System stark von der Zeilenlänge beeinflusst wird; sehr lange Zeilen erhöhen die Lesegeschwindigkeit geringfügig, verringern jedoch das Verständnis und tragen zu Eye-Tracking-Fehlern bei. Einige Studien deuten darauf hin, dass längere Zeilen online besser abschneiden als in gedruckter Form , aber das geht immer noch nur bis zu etwa 10 Zoll, und vor allem für die Geschwindigkeit des Lesens von Prosa.

PortabilityEdit

Programmcode sollte keine „hartcodierten“ (wörtlichen) Werte enthalten, die sich auf Umgebungsparameter beziehen, wie absolute Dateipfade, Dateinamen, Benutzernamen, Hostnamen, IP-Adressen, URLs, UDP/TCP-Ports. Andernfalls wird die Anwendung nicht auf einem Host ausgeführt, der ein anderes Design als erwartet hat. Ein sorgfältiger Programmierer kann solche Variablen parametrisieren und für die Hosting-Umgebung außerhalb der eigentlichen Anwendung konfigurieren (z. B. in Eigenschaftendateien, auf einem Anwendungsserver oder sogar in einer Datenbank). Vergleichen Sie das Mantra eines „Single Point of Definition“(SPOD).

Als Erweiterung sollten Ressourcen wie XML-Dateien auch Variablen anstelle von Literalwerten enthalten, andernfalls kann die Anwendung nicht in eine andere Umgebung portiert werden, ohne die XML-Dateien zu bearbeiten. Wenn beispielsweise J2EE-Anwendungen auf einem Anwendungsserver ausgeführt werden, können solche Umgebungsparameter im Bereich der JVM definiert werden, und die Anwendung sollte die Werte von dort abrufen.

ScalabilityEdit

Entwerfen Sie Code mit Skalierbarkeit als Designziel, da in Softwareprojekten sehr oft neue Funktionen zu einem Projekt hinzugefügt werden, das größer wird. Daher wird die Möglichkeit, einer Software-Codebasis neue Funktionen hinzuzufügen, zu einer unschätzbaren Methode beim Schreiben von Software

Wiederverwendbarkeitbearbeiten

Wiederverwendung ist ein sehr wichtiges Designziel in der Softwareentwicklung. Die Wiederverwendung senkt die Entwicklungskosten und verkürzt auch die Entwicklungszeit, wenn die wiederverwendeten Komponenten oder Module bereits getestet wurden. Sehr oft beginnen Softwareprojekte mit einer vorhandenen Baseline, die das Projekt in seiner vorherigen Version enthält, und je nach Projekt werden viele vorhandene Softwaremodule und -komponenten wiederverwendet, was die Entwicklungs- und Testzeit verkürzt und somit die Wahrscheinlichkeit erhöht, ein Softwareprojekt termingerecht zu liefern.

Bauleitlinienbearbeiten

Ein allgemeiner Überblick über alle oben genannten: