C-Entwicklung unter Linux - Codierungsstil und Empfehlungen - IX.

Einleitung

Sie fragen sich vielleicht, was mit dem Titel gemeint ist. Code ist Code, oder? Es ist wichtig, fehlerfrei zu sein, und das war's, was sonst? Entwicklung ist mehr als das Schreiben von Code und dessen Testen/Debuggen. Stellen Sie sich vor, Sie müssten die Arbeit eines anderen lesen, und ich nehme an, Sie haben das bereits getan, und alle Variablen heißen foo, bar, baz, var usw. Und der Code wird weder kommentiert noch dokumentiert. Wahrscheinlich wirst du den plötzlichen Drang verspüren, unbekannte Götter anzurufen, dann in die örtliche Kneipe zu gehen und deinen Kummer zu ertränken. Sie sagen, dass du anderen nicht antun solltest, was du nicht willst, dass es dir geschieht, daher wird sich dieser Teil auf allgemeine Codierungsrichtlinien konzentrieren, plus GNU-spezifische Ideen, die dir helfen werden, deinen Code akzeptieren zu lassen. Sie sollten die vorherigen Teile dieser Serie gelesen und verstanden haben, sowie alle Übungen lösen und vorzugsweise so viel Code wie möglich gelesen und geschrieben haben.

Empfehlungen

Bevor Sie beginnen, beachten Sie bitte die eigentliche Bedeutung des obigen Wortes. Ich möchte Ihnen in keiner Weise sagen, wie Sie Ihren Code schreiben sollen, noch erfinde ich diese Empfehlungen. Diese sind das Ergebnis jahrelanger Arbeit erfahrener Programmierer, und viele gelten nicht nur für C, sondern auch für andere Sprachen, interpretiert oder kompiliert.

Ich denke, die erste Regel, die ich betonen möchte, ist: Kommentieren Sie Ihren Code, prüfen Sie dann, ob Sie genug kommentiert haben, und kommentieren Sie dann noch mehr. Dies ist nicht vorteilhaft für andere, die Ihren Code lesen/verwenden, sondern auch für Sie. Seid überzeugt, dass ihr euch nach zwei oder drei Monaten nicht mehr genau daran erinnern werdet, was ihr schreiben wolltet, noch werdet ihr wissen, was int ghrqa34; bedeuten sollte, wenn überhaupt. Gute Entwickler kommentieren (fast) jede Zeile ihres Codes so gründlich wie möglich, und der Lohn ist mehr, als Sie vielleicht auf den ersten Blick denken, trotz der erhöhten Zeit, die für das Schreiben des Programms benötigt wird. Ein weiterer Vorteil ist, dass durch das Kommentieren das, was wir tun wollten, besser in Erinnerung bleibt, denn so funktioniert unser Gehirn, so dass Sie sich nicht mehr an Ihren Code erinnern müssen, sondern sich ein paar Monate vorspulen und sich fragen, wer Ihren Code geschrieben hat. Oder warum.

Dem C-Parser ist es egal, wie geordnet Ihr Code ist. Das bedeutet, dass Sie ein typisches "Hello, world"-Programm wie dieses schreiben können, und es würde immer noch kompilieren:

#include <stdio.h> int main(){printf("Hello, world!"); return 0;}

Es scheint viel lesbarer zu sein, so wie wir es das erste Mal geschrieben haben, nicht wahr? Die allgemeinen Regeln für die Formatierung sind: eine Anweisung pro Zeile, wählen Sie Ihre Tabulatorbreite und seien Sie konsistent, aber stellen Sie sicher, dass sie den Richtlinien des Projekts entspricht, wenn Sie an einem arbeiten, verwenden Sie auch großzügig Leerzeilen, um verschiedene Teile des Programms abzugrenzen, zusammen mit Kommentaren, und schließlich, Obwohl dies nicht unbedingt mit dem Programmierstil zusammenhängt, sollten Sie, bevor Sie ernsthaft mit dem Programmieren beginnen, einen Editor finden, der Ihnen gefällt, und lernen, ihn gut zu verwenden. Wir werden demnächst einen Artikel über Editoren veröffentlichen, aber bis dahin hilft Ihnen Google mit einigen Alternativen. Wenn Sie Leute in Foren, Mailinglisten usw. sagen hören "Editor x ist, Editor y FTW!", ignorieren Sie sie. Das ist eine sehr subjektive Angelegenheit und was für mich gut ist, ist vielleicht nicht so gut für Sie, also probieren Sie zumindest einige der für Linux verfügbaren Editoren für ein paar Tage aus, bevor Sie überhaupt anfangen, eine Meinung zu bilden.

Seien Sie konsistent bei der Benennung von Variablen. Achten Sie auch darauf, dass die Namen zu den anderen passen, damit das gesamte Programm harmoniert. Dies gilt auch dann, wenn Sie der einzige Autor der Software sind, da sie später einfacher zu warten ist. Erstellen Sie eine Liste der verwendeten Präfixe und Suffixe (e.g. max, min, get, set, is, cnt) und verwenden Sie diese, sofern nicht anders gefragt. Konsistenz ist hier das Schlüsselwort.

GNU-spezifische Richtlinien

Was folgt, ist eine Zusammenfassung der GNU-Codierungsstandards, denn wir wissen, dass Sie solche Dinge nicht gerne lesen. Wenn Sie also Code schreiben, der in das GNU-Ökosystem passen möchte, ist dies das Dokument, das Sie lesen sollten. Selbst wenn Sie dies nicht tun, ist es immer noch eine gute Lektüre, um zu erfahren, wie man den richtigen Code schreibt.

Dieses Dokument ist immer eine vollständige Lektüre wert, wenn Sie GNU-Software erstellen oder pflegen, aber Sie finden die wichtigsten Teile unten. Eine erste Frage, die es zu erwähnen gilt, ist der Umgang mit Funktionsprototypen. Bitte gehen Sie zurück zu dem Teil, der sich damit befasst, wenn Sie Probleme haben. Die Idee ist: "Wenn Sie Ihre eigenen Funktionen haben, verwenden Sie eine Prototyp-Deklaration vor main() und definieren Sie dann die Funktion, wenn nötig." Hier ist ein Beispiel:

#include <stdio.h>

int func (int, int)

int main() 

[...]

int func (int x, int z)

[...]

Verwenden Sie die richtige und konstante Einrückung. Das kann nicht oft genug betont werden. Erfahrene Programmierer mit jahrelanger Erfahrung im Code werden es sehr übel nehmen, wenn Sie Code mit falscher Einrückung einreichen. In unserem Fall ist der beste Weg, sich daran zu gewöhnen, wie GNU dies macht, die Verwendung von GNU Emacs (obwohl dies in keiner Weise unsere Art ist, Ihnen zu sagen, dass "GNU Emacs gut für Sie ist, verwenden Sie es.", da wir Befürworter des freien Willens und der freien Wahl sind), wobei das Standardverhalten für C-Code die Einrückung bei zwei Leerzeichen und geschweifte Klammern in einer Zeile für sich selbst ist. Womit wir bei einem weiteren wichtigen Punkt wären. Manche Leute verwenden Zahnspangen wie diese:

while (var == 1) {
  code...
}

...während andere, einschließlich GNU-Leute, es so machen:

while (var == 1)
{
  code...
}

Dies gilt natürlich auch für bedingte Ausdrücke, Funktionen und alle Gelegenheiten, bei denen Sie geschweifte Klammern in C-Code verwenden müssen. Soweit bemerkt, ist diese Wahl etwas sehr GNU-spezifisches, und wie viel davon Sie respektieren, hängt ausschließlich von Ihrem Geschmack und Ihrer Haltung zu diesem Thema ab.

Unser nächstes Problem ist ein technisches und ein Versprechen, das ich halten musste: das malloc()-Problem. Neben dem Schreiben relevanter und aussagekräftiger Fehlermeldungen, im Gegensatz zu denen, die wir alle in anderen Betriebssystemen gesehen haben, überprüfen Sie, ob malloc() und Co. immer Null zurückgeben. Dies sind sehr ernste Probleme, und Sie erhalten eine Lektion über malloc() und wann Sie es verwenden sollten. Inzwischen wissen Sie, was es bedeutet, Speicher automatisch oder statisch zuzuweisen. Aber diese Methoden decken nicht alle Grundlagen ab. Wenn Sie Speicher zuweisen müssen und mehr Kontrolle über den Vorgang haben müssen, gibt es malloc() und Freunde für die dynamische Zuordnung. Sein Zweck ist es, verfügbaren Speicher aus dem Heap zuzuweisen, dann verwendet das Programm den Speicher über einen Zeiger, den malloc() zurückgibt, dann muss dieser Speicher free()d sein. Und "muss" ist mit Großbuchstaben in 2 Fuß Buchstaben mit einer brennenden roten Farbe zu schreiben. Das war's auch schon mit malloc(), und die Gründe dafür wurden bereits weiter oben im vorherigen Teil dargelegt.

Es wird dringend empfohlen, in all Ihren Befehlszeilenprogrammen eine konsistente Benutzeroberfläche zu verwenden. Wenn Sie bereits ein erfahrener GNU/Linux-Benutzer sind, haben Sie bemerkt, dass fast alle Programme –version und –help haben, plus zum Beispiel -v für ausführlich, falls dies der Fall ist. Wir werden hier nicht auf alles eingehen; Holen Sie sich eine Kopie der GNU Coding Standards, Sie werden sie sowieso brauchen.

Obwohl ich persönlich dazu neige, dies zu übersehen, und für viele ist es ein kleines Problem, wird es die Lesbarkeit Ihres Codes verbessern, denn so funktioniert unser Gehirn. Die Idee ist: Wenn Sie Zweifel an der Verwendung von Räumen haben, verwenden Sie sie. Zum Beispiel:

int func (var1, var2);

int func(var1,var2);

Es gibt einige, die besagen, dass Sie verschachtelte Wenns nicht vermeiden können. Es gibt andere, die sagen: "Warum verschachtelte Wenns vermeiden?", und es gibt wieder andere, die einfach keine verschachtelten Wenns verwenden. Sie werden sich Ihre eigene Meinung dazu bilden, wenn die Zeit vergeht und die Codezeilen, die Sie schreiben, zunehmen. Die Idee ist, wenn Sie sie verwenden, machen Sie sie so lesbar wie menschenmöglich, da sie leicht zu Beinahe-Spaghetti-Code führen können, der schwer zu lesen und zu warten ist. Und auch hier gilt: Verwenden Sie Kommentare.

Der GNU-Codierungsstandard besagt, dass es gut ist, wenn der Code so portabel wie möglich ist, "aber nicht im Vordergrund". Was die tragbare Hardware angeht? Das hängt vom Zweck des Programms ab und davon, welche Maschinen Ihnen zur Verfügung stehen. Wir beziehen uns mehr auf die Software-Seite, nämlich die Portabilität zwischen Unix-Systemen, ob Open Source oder nicht. Vermeiden Sie ifdefs, wenn Sie können, vermeiden Sie Annahmen bezüglich Dateispeicherorten (z.B. installiert Solaris Software von Drittanbietern unter /opt, während BSD und GNU/Linux dies nicht tun) und streben Sie generell nach sauberem Code ab. Apropos Annahmen: Gehen Sie nicht einmal davon aus, dass ein Byte aus acht Bit besteht oder dass der Adressraum einer CPU eine gerade Zahl sein muss.

Die Dokumentation Ihres Codes in Form von Handbuchseiten und gut geschriebenen READMEs usw. ist ein weiterer wichtiger Aspekt der Softwareentwicklung. Ja, es ist eine mühsame Aufgabe, aber wenn Sie keinen Dokumentationsautor in Ihrem Team haben, liegt es in Ihrer Verantwortung, es zu tun, da jeder gute Programmierer seine Arbeit von A bis Z macht.

Schlussfolgerung

Das nächste Mal machen wir da weiter, wo wir hier aufgehört haben: von der Idee zu einem kompletten Programm, mit Makefiles, Dokumentation, Release-Zyklen und all den lustigen Dingen. Die einzige Übung, die ich für Sie habe, besteht darin, die GNU-Codierungsstandards zu überfliegen und Ihren Code entsprechend zu modifizieren. Und mach dich bereit, das nächste Mal ist es Zeit für Spaß!

Hier ist, was Sie als nächstes erwarten können:

• I.C.-Entwicklung unter Linux – Einführung
• II. Vergleich zwischen C und anderen Programmiersprachen
• III. Typen, Operatoren, Variablen
• IV. Flusskontrolle
• V. Funktionen
• VI. Zeiger und Arrays
• VII. Strukturen
• VIII. Grundlegende I/O
• IX. Codierungsstil und Empfehlungen
• X. Erstellen eines Programms
• XI. Paketierung für Debian und Fedora
• XII. Ein Paket in die offiziellen Debian-Repositories bekommen