perlstyle

perlstyle Dokumentation | Download als POD | Wie kann ich hier etwas ändern?

BEZEICHNUNG

perlstyle - Perl Gestaltungsrichtlinien

BESCHREIBUNG

Jeder Programmierer hat seine eigenen Vorlieben bezüglich der Quellcodeformatierung, aber es gibt einige generelle Richtlinien, die Ihre Programme leichter lesbar, verständlicher und besser wartbar machen.

Am wichtigsten ist es, Programme immer mit der Kompilieroption -w oder ab Perl 5.6 mit dem Pragma use warnings auszuführen. Man kann diese Option explizit für bestimmte Codebereiche mit dem Pragma no warnings oder über die Perl-Variable $^W deaktivieren. Man sollte das Programm auch immer mit dem Pragma use strict ausführen oder zumindest gut begründen können, warum man darauf verzichtet. Die Verwendung der Pragmas use sigtrap oder auch use diagnostics kann auch oft nützlich sein.

Wenn es um die Ästhetik des Codes geht, gibt es für Larry Wall eigentlich nur einen Punkt, der ihm wirklich wichtig ist: Dass die schließende geschweifte Klammer } bei einem mehrzeiligen Block dieselbe Einrückung wie das Schlüsselwort haben sollte, mit dem der Block begonnen wurde. Es gibt für ihn noch weitere Richtlinien, die er aber nicht so streng sieht:

• Einrückung um jeweils vier Spalten.

• Die öffnende geschweifte Klammer sollte wenn möglich in derselben Zeile wie das den Block beginnende Schlüsselwort sein. Falls nicht möglich, dann soll sie eingerückt sein.

• Ein Leerzeichen vor der öffnenden geschwungenen Klammer bei einem mehrzeiligen Block.

• Ein Block, der nur aus einer Zeile besteht, kann inklusive der geschweiften Klammern in eine Zeile gepackt werden.

• Kein Leerzeichen vor einem Semikolon.

• Kein abschließendes Leerzeichen bei einem "kurzen" einzeiligen Block.

• Leerzeichen vor und nach den meisten Operatoren.

• Leerzeichen um einen "komplexen" Indexausdruck herum (in eckigen Klammern).

• Codeteile, die verschiedenes machen, sollten voneinander durch Leerzeilen getrennt sein.

• Das else in einer if-then-else Konstruktion sollte nicht mit der schließenden Klammer davor und der öffnenden Klammer dahinter auf einer Zeile stehen ("uncuddled elses").

• Keine Leerzeichen zwischen dem Funktionsnamen und der zugehörigen öffnenden Klammer.

• Ein Leerzeichen nach jedem Komma.

• Lange Zeilen sollen nach einem Operator umgebrochen werden (mit Ausnahme von and und or ).

• Space after last parenthesis matching on current line. (Was bedeutet das? Bitte um eine sinnvolle Übersetzung. Anm.d.Übers. )

• Zusammengehörige Sachen sollten auch gleich weit eingerückt werden.

• Überflüssige Interpunktion vermeiden, so lange die Verständlichkeit nicht darunter leidet.

Larry hat seine Gründe für jeden dieser Punkte, aber er verlangt nicht, dass da jeder genauso denkt wie er.

Hier sind noch einige weitere substanzielle Stilfragen, über die man nachdenken kann:

• Nur weil man etwas auf eine bestimmte Weise machen kann , heißt das nicht, dass man es auch so machen soll . Perl bietet vom Design her mehrere Möglichkeiten, etwas zu machen, daher sollte man sich überlegen, diejenige zu wählen, die am lesbarsten ist. Zum Beispiel ist

      open(FOO,$foo) || die "Kann $foo nicht öffnen: $!";
  

  besser als

      die "Kann $foo nicht öffnen: $!" unless open(FOO,$foo);
  

  weil in der zweiten Variante der eigentliche Punkt dieses Statements in einem Modifier versteckt ist. Andererseits ist

      print "Starte Analyse\n" if $verbose;
  

  besser als

      $verbose && print "Starte Analyse\n";
  

  denn der entscheidende Punkt ist nicht, ob der Benutzer -v eingegeben hat oder nicht.

  Auch bedeutet die Möglichkeit, dass ein Operator Default-Argumente erlaubt, nicht, dass man sie auch benutzen muss. Diese Defaults sind für faule Systemprogrammierer, die Wegwerf-Programme schreiben. Wenn Sie wollen, dass Ihr Programm lesbar ist, dann schreiben Sie lieber das Argument explizit hin.

  Noch etwas: Nur weil man Klammern in vielen Fällen weglassen kann , heißt das nicht, dass man das auch muss:

      return print reverse sort num values %array;
      return print(reverse(sort num (values(%array))));
  

  Wenn man Zweifel hat, lieber Klammern setzen. Zumindest erlaubt es einem armen Knilch, im vi auf der %-Taste herumdrücken zu können.

  Selbst wenn Sie keine Zweifel haben, denken Sie an das geistige Wohlergehen der Person, die den Code nach Ihnen warten muss und die möglicherweise Klammern an die falschen Stellen setzt.

• Machen Sie keine komischen Verrenkungen, um aus einer Schleife am Anfang oder Ende auszusteigen, wo Perl doch über den Operator last verfügt, so dass man in der Mitte aussteigen kann. Rücken Sie die Zeile nur etwas nach links aus, um sie besser sichtbar zu machen:

      LINE:
          for (;;) {
              statements;
            last LINE if $foo;
              next LINE if /^#/;
              statements;
          }
  

• Haben Sie keine Angst davor, Labels bei Schleifen zu benutzen - sie verbessern die Lesbarkeit und erlauben es, aus mehrfach verschachtelten Schleifen auszusteigen, wie im vorigen Beispiel.

• Vermeiden Sie es grep() (oder map() ) oder `Backticks` in einem void-Kontext zu benutzen, d.h. wenn Sie die Rückgabewerte sowieso wegwerfen. All diese Funktionen haben Rückgabewerte, also benutzen Sie sie. Andernfalls nehmen Sie stattdessen besser eine foreach() -Schleife oder die Funktion system() .

• Wenn man Eigenschaften benutzt, die nicht unbedingt auf jeder Maschine implementiert sind, dann verbessert man die Portierbarkeit, wenn man das Konstrukt in einem eval testet, um zu schauen, ob es fehlschlägt. Wenn man weiß, in welcher Version oder welchem Patchlevel ein bestimmtes Feature implementiert wurde, dann kann man $] ( $PERL_VERSION , wenn man das Pragma ENglish benutzt) testen, um zu sehen, ob es vorhanden sein wird. Das Modul Config erlaubt es auch, Werte abzufragen, die dem Programm configure übergeben wurden, als dieses Perl gebaut wurde.

• Wählen Sie Bezeichner, die man sich gut merken kann.

• Auch wenn kurze Bezeichner wie $maches vielleicht in Ordnung sind, sollte man generell Unterstriche benutzen, um Wörter zu trennen. Es ist im Allgemeinen einfacher $Variablennamen_wie_diese zu lesen als $VariablennamenWieDiese, besonders für jemanden, der Englisch nicht als Muttersprache hat. Auch ist es eine einfache Regel, die konsistent mit $VARIABLENNAMEN_WIE_DIESE funktioniert. (Anm. d. Übers.: Ob dies im Deutschen tatsächlich so gilt, kann man hinterfragen. Im Deutschen sind lange Wörter recht häufig, weshalb ein Deutsch-Muttersprachler damit weniger Probleme haben sollte.)

• Es kann hilfreich sein, wenn man Groß-/Kleinschreibung von Variablennamen dazu nutzt, den Geltungsbereich deutlich zu machen. Beispiel:

      $NUR_GROSSE_BUCHSTABEN        Nur Konstanten (Vorsicht vor Konflikten mit Perl-Variablen!)
      $Ein_Paar_Grossbuchstaben     Globale/Statische Variablen im ganzen Package
      $keine_grossbuchstaben_hier   Funktionslokale Variablen mit my() oder local()
  

  Funktions- und Methodennamen scheinen in kompletter Kleinschreibung am besten zu wirken. Beispiel: $obj->>as_string().

  Man kann einen Unterstrich am Anfang benutzen, um deutlich zu machen, dass eine Variable oder Funktion nicht außerhalb des Package benutzt werden soll, in dem sie definiert ist.

• Wenn Sie einen wirklich haarigen regulären Ausdruck haben, benutzen Sie den Modifier /x und fügen Sie einigen Leerraum in den Ausdruck ein, damit er etwas weniger nach Leitungsrauschen aussieht. Benutzen Sie keinen Schrägstrich ( / ) als Begrenzer, wenn Ihr regulärer Ausdruck Schrägstriche oder rückwärtige Schrägstriche (Backslashes, \ ) enthält.

• Benutzen Sie die Operatoren "and" und "or", um viele Klammern bei Listenoperatoren und die Häufigkeit von Operatoren aus Sonderzeichen (wie && und || ) zu vermeiden. Rufen Sie Ihre Subroutinen so auf, als wären Sie (eingebaute) Funktionen oder Listenoperatoren, um die Anhäufung von Und-Zeichen und Klammern zu vermeiden.

• Benutzen Sie "Here"-Dokumente statt wiederholter print()-Anweisungen.

• Richten Sie Zusammengehöriges vertikal untereinander aus, besonders wenn es sowieso zu lang wäre, um in eine Zeile zu passen.

      $IDX = $ST_MTIME;
      $IDX = $ST_ATIME       if $opt_u;
      $IDX = $ST_CTIME       if $opt_c;
      $IDX = $ST_SIZE        if $opt_s;
  
      mkdir $tmpdir, 0700 or die "Kann $tmpdir nicht anlegen: $!";
      chdir($tmpdir)      or die "Kann in $tmpdir nicht wechseln: $!";
      mkdir 'tmp',   0777 or die "Kann $tmpdir/tmp nicht anlegen: $!";
  

• Prüfen Sie immer den Rückgabewert von Systemaufrufen. Gute Fehlermeldungen sollten nach STDERR ausgegeben werden, den Namen des Fehler verursachenden Programms und den fehlgeschlagenen Systemaufruf mit seinen Argumenten enthalten, sowie (SEHR WICHTIG) die Standard-Systemmeldung des Fehlers. Hier ist ein einfaches aber ausreichendes Beispiel:

      opendir(D, $dir)     or die "Ein opendir auf $dir schlug fehl: $!";
  

• Richten Sie Transliterationen untereinander aus, wenn es sinnvoll ist:

      tr [abc]
         [xyz];
  

• Denken Sie an Wiederverwendbarkeit. Warum sollte man Denkarbeit auf ein Wegwerf-Programm verwenden, wenn man etwas Ähnliches vielleicht noch einmal braucht? Überlegen Sie, Ihren Code allgemeiner zu gestalten. Überlegen Sie, ein Modul oder eine Objektklasse zu schreiben. Überlegen Sie, Ihren Code sauber unter use strict und use warnings (oder -w ) lauffähig zu machen. Überlegen Sie, Ihren Code weiterzugeben. Überlegen Sie, Ihre ganze Weltanschauung zu ändern. Überlegen Sie, ... ah, schon gut.

• Seien Sie konsistent.

• Seien Sie nett.

-- StraT - 23 Aug 2003
-- HaraldBongartz - 26 Apr 2005

anmerkung: "Space after last parenthesis matching on current line." könnte heißen: if (bla) { statt if (bla){

siehe http://www.perlmonks.org/?node_id=509770

-- TinaMueller - 18 Nov 2005

Tipp: PerlTidy kann das Aussehen von Quellcode erheblich verbessern. Weiteres zu PerlTidy? unter http://perltidy.sourceforge.net/

-- GwenDragon - 25 Jan 2006