Wie stellen Sie sicher, dass Sie als Programmierer Qualitäts-C-Code geschrieben haben?

Jemand hat einige Compiler-Switches erwähnt, aber syntaktisch reibungslosen Code zu haben wird kein Qualitäts-Endprodukt garantieren, da es mehr Software-Qualität gibt.

Es gibt verschiedene Klassifizierungen von Softwarequalitäten, aber hier ist eine Liste, die Sie als Checkliste verwenden können:

• Korrektheit (funktioniert es entsprechend der Spezifikation?)
• Zuverlässigkeit (Kann der Benutzer davon abhängig sein?)
• Robustheit (funktioniert es in unerwarteten Situationen?)
• Leistung (macht es den Job schnell genug für den Benutzer?)
• Benutzerfreundlichkeit (ist es benutzerfreundlich?)
• Überprüfbarkeit (Können seine Eigenschaften leicht verifiziert werden?)
• Wartbarkeit (können Änderungen leicht vorgenommen werden?)
  • Reparierbarkeit (können Defekte innerhalb einer angemessenen Zeit behoben werden?)
  • Evolvability (Können neue Funktionen einfach hinzugefügt werden?)
• Wiederverwendbarkeit (Kann der Code leicht in anderen Projekten verwendet werden?)
• Portabilität (Kann es in verschiedenen Umgebungen problemlos ausgeführt werden?)
• Verständlichkeit (Können Betreuer das leicht verstehen?)
• Interoperabilität (wie gut kooperiert es?)
• Produktivität (effiziente und performante Lieferung)
• Aktualität (Fähigkeit, pünktlich zu liefern)
• Sichtbarkeit (Sind alle Schritte klar dokumentiert?)

Aktivieren Sie Warnungen in Ihrem Compiler. Mit gcc verwende ich diese Flags:

Wenn Ihr Code nicht geändert werden kann, um keine Warnungen zu erzeugen, lassen Sie die -Werror fallen oder verwenden Sie nicht das spezifische Flag, das die Warnung erzeugt.

Traditionell haben Leute Fussel verwendet, um damit zu helfen.

Es gibt viele Aspekte für die Qualität des Codes und Tonnen von Artikeln, Bücher, Blogs

aber ich kann Ihnen diese als Anfang empfehlen:

Code vollständig

Code sicher

Verwenden Sie ein statisches Analyse-Tool, traditionell Lint genannt, aber ich habe Schiene verwendet, was gut ist. Siehe Empfehlungen in dieser Frage . Persönlich würde ich empfehlen, Warnungen zu aktivieren und zu beheben.

In Bezug auf die Regeln

• Vertraue Eingabedaten nicht - validiere alles, Größe, Typ, Inhalt.
• Schutz vor Pufferüberläufen - strcat und viele andere sind nicht sicher.
• Verwenden Sie Unit-Tests, ddj-Artikel .
• Lassen Sie Ihren Code von jemand anderem überprüft werden
• Machen Sie keine Annahmen.
• Halten Sie die Funktionen kurz und testen Sie sie gründlich.
• Verwenden Sie aussagekräftige Namen.
• Schreibe lesbaren Code.
• Sei nicht faul - wenn du etwas ändern musst, um es aussagekräftiger zu machen, mach es eher früher als später.

Bearbeiten: Spezifisch für C, ist diese Liste von C gotchas eine wichtige Lektüre, und obwohl es so ist Für C ++ lohnt es sich, den CERT C ++ Secure Coding Standard durchzugehen >     

Eine vorherige Diskussion, was-sind-einige -good-resources-for-learning-c-beyond-kr , könnte auf weitere (Bücher) Beispiele verweisen.

Es ist schwer für sich selbst zu sehen, ob Sie Qualitätscode schreiben oder nicht, sicher, es gibt Tonnen von Automatisierung und Standards da draußen, aber wie kann man alles anwenden, was sie dort gesehen haben?

Hier bin ich ein großer Fan von Peer Review als Methode, um die Codequalität zu beurteilen. Lassen Sie andere sehen (und auch lernen) von Ihrem Code und das wird der Richter für Qualität.

Bisher haben die Menschen Werkzeuge erwähnt. Aber ab einem bestimmten Punkt gibt es wirklich nur eine Möglichkeit, die Qualität des von Ihnen geschriebenen Codes wirklich zu verbessern:

Code schreiben.

Schreibe Unit Tests!

Es mag ein bisschen mühsamer sein, Komponententests in C zu schreiben, verglichen mit moderneren Sprachen, aber es lohnt sich immer noch.

Ich würde sagen, dass richtige Komponententests der beste Weg sind, um die Qualität jedes Codes zu gewährleisten. Sie können alle statischen Analyse-Tools und Code-Überprüfungen verwenden, die Sie möchten, aber nichts geht über das Ausführen des Codes und das Überprüfen der Ergebnisse hinaus.

Es hängt teilweise davon ab, was Sie mit "Qualität C" -Code meinen.

Ein wichtiger Aspekt des Programms ist "macht es das, wofür es entworfen wurde"? Das ist schwer zu messen, ist aber entscheidend.

Dann müssen Sie wissen, ob der Code für Compiler akzeptabel ist - mit Satz von GCC-Compiler-Optionen zur Verfügung gestellt von Cristoph würde anzeigen, dass der Code in gutem Zustand ist. (Obwohl ich über -Wno-long-long streiten würde, hängt es davon ab, wohin der Code verschoben werden muss).

Das Code-Layout ist wichtig. Ist der Code sowohl für Menschen als auch für Compiler lesbar? Ist das Layout einheitlich? Ist es in einem der Standardformate - es gibt mehrere, alle mit großen Folgen, und solange Sie einen von ihnen konsequent verwenden, sollte der Code in Ordnung sein. Ist es angemessen kommentiert? Das bedeutet genug Kommentare, aber nicht zu viele! Die Datei sollte einen Header-Kommentar haben, der anzeigt, was drin ist - und wahrscheinlich, wer sie geschrieben hat und vielleicht die Lizenz, unter der sie verteilt wird. Es gab mehrere Fragen zu SO dazu, einschließlich Professional # enthalten Kommentare . Das Schreiben von Code in einen guten Layout-Standard ist jedoch nach kurzer Zeit Routine.

Die Dokumentation kann relevant sein - ist in der Regel relevant. Wie würde jemand anders wissen, dass der Code existiert, was er tut, wie er verwendet wird, wann er zu verwenden ist, wann er nicht benutzt wird?

Der Code sollte mit ausreichend guten Algorithmen geschrieben werden - er sollte keine exorbitanten Mengen an Speicher, Platte oder CPU-Zeit verbrauchen. Es sollte auch keine Ressourcen verlieren. Es macht auch keinen Sinn, den letzten CPU-Zyklus der Leistungsverbesserung aus einer Routine herauszuholen, die einmal pro Programmlauf für einige Millisekunden beim Start verwendet wird, es sei denn, Sie können nachweisen, dass es sich um einen Leistungsengpass für das Programm handelt Programm als Ganzes.

Wouter van Nifterick hat ein ausgezeichnete Reihe von Zeigern auch.

Einige moderne Software-Lebenszyklus-Praktiken, die die Code-Qualität erzwingen:

• Integrationstests (geplant beim Projektstart)
• Peer-Reviews von Code (während der Entwicklung)
• Paar-Programmierung (während der Entwicklung)
• die Verwendung von konsolidierten Bibliotheken (anstelle eines Ansatzes, der das Rad neu erfindet)

Letzteres kann insbesondere für die Sprache C gelten.