Eine der besten Antworten wäre bisher, einen Kommentar von Amro zu zitieren:

"derselbe Autor (Richard Johnson)" hat ein Buch 'Die Elemente von MATLAB Style' (siehe auch Wiki ) 2011:

  

Inhaltsverzeichnis

     

1. Allgemeine Grundsätze
  
2. Formatierung
  
3. Benennung
  
4. Dokumentation
  
5. Programmierung
  
6. Dateien und Organisation
  
7. Entwicklung.
  

Loren hat einen Blogeintrag mit der Überprüfung des Buches . Ich werde hier nur der Kommentarzeile folgen:

• 7 Aufgeteilte lange Codezeilen an magischen Punkten - Ich finde das nützlich, da es ein absoluter Schmerz ist, in jedem Editor weit nach rechts zu gehen, obwohl es möglich ist.

• 10 Verwenden Sie keine harten Registerkarten - Dies hilft, bei der Arbeit in einer Gruppe mit möglicherweise unterschiedlichen Bearbeitungsumgebungen gesund zu bleiben.

• 43 Sinnvolle Namen für Variablen mit großem Gültigkeitsbereich verwenden - Dies erleichtert das Lesen, Verstehen und Debuggen von Code erheblich.

• 69 Name Funktionen für was sie tun - Da Funktionen eine Aktion ausführen, sollte der Name Informationen über die Aktion enthalten.

• 86 Verwenden Sie eine sortierbare Nummerierung in Datendateinamen - Wenn Sie viele ähnliche Datendateien haben, kann Ihnen ein rationelles Nummerierungsschema nur helfen.

• 97 Seien Sie sicher, dass diese Kommentare mit dem Kodex übereinstimmen - ich werde niemals die Zeit vergessen, in der mein Doktorvater mich anrief, weil er wirklich irritiert war. Ich hatte ihm eine Kopie eines Fortran-Programms hinterlassen, das reichhaltige Kommentare enthielt, und das letzte war: "Ignoriere alle obigen Kommentare; sie waren für eine frühere Version."

Vermeiden Sie kryptischen Code - Ich habe festgestellt, dass das Schreiben von kryptischem Code im Allgemeinen weniger kostet, als ich in Bezug auf gute Dinge erwarte, und mehr Kopfschmerzen, als es rechtfertigt. Gelegentlich habe ich kryptischen Code für etwas Zeitkritisches eingesetzt. Wenn ich das tue, versuche ich, es vollständig zu kommentieren, einschließlich einer geradlinigen Implementierung in den Kommentaren, die ich getestet habe. Auf diese Weise verstehe ich, wenn der Performance-Kompromiss sich ändert, was der Code tun soll und habe zwei Startoptionen für eine Code-Aktualisierung.

• 150, 151 Minimiere die Verwendung globaler Variablen und minimiere die Verwendung globaler Konstanten - das würde ich selbst noch stärker betonen. Es gibt überlegene Techniken für den Umgang mit Informationen, die Sie teilen möchten, egal ob es sich um Funktions-Handles, Klassen und deren Eigenschaften oder um andere Methoden handelt. Diese Techniken sind aus vielen Gründen viel sicherer zu verwenden - z. B. können leichter gesteuerte Nebenwirkungen, falls gewünscht, und Code für die Parallelität potentiell geeigneter werden.

• 172 Verwenden Sie Parenthese - Klarheit der Bedeutung ist von größter Bedeutung, insbesondere wenn andere den Code verstehen, ändern oder übersetzen müssen.

• 176 Vermeiden Sie die Verwendung von eval wenn möglich - Ich bin mir sicher, dass es einigen MATLAB-Benutzern nicht so scheint, aber Eval ist die meiste Zeit vermeidbar.

• 185-188 Die erste dieser Optionen ist Komplizierte bedingte Ausdrücke vermeiden - Diese Einträge enthalten einige nützliche Hinweise zum Umgang mit bedingten Konstrukten, zur Reihenfolge der Fälle usw.

• 271-275 Das erste von diesen ist Schreiben kleiner Tests - ich liebe, dass Richard das Testen zu einem zentralen Grundsatz dieses Stilleitfadens gemacht hat. Ich sehe nicht, wie Programmierer ohne eine robuste Testsuite funktionieren.

Fazit

Das Buch scheint zu allgemein zu sein, verglichen mit dem Originaldokument von 2002. Ich werde es weiter lesen und mehr Einsichten geben, aber es scheint meinem Verständnis von Strenge, das für einen Codierungsstandard erforderlich ist, nicht ganz zu entsprechen. Es fügt viele allgemeine Ideen zusammen, die für den Anfänger-Programmierer nützlich sind, aber nicht streng zu programmieren, so dass sie Code automatisch testen können (wieder ein PEP8 ).