Diskussion:Einrückungsstil

aus Wikipedia, der freien Enzyklopädie

Die Schreibweise z--, nicht --z, stammt wie auch das Beispiel direkt aus [1] also bitte nicht einfach gedankenlos ändern, sondern erst die GNU Code Conventions lesen. Außerdem ist z-- wesentlich gebräuchlicher als --z, siehe auch Diskussion:Beautifier --ChristianHujer 20:55, 3. Apr 2005 (CEST)

Das ist nicht gedankenlos. Im Gegenteil. Siehe Diskussion:Beautifier. Also --z verwenden! --217.95.168.102 20:16, 5. Apr 2005 (CEST)

Offensichtlich doch gedankenlos. Bei den meisten heutigen Compilern und CPUs besteht zwischen --z und z-- kein Unterschied. Mit einem Uralt-Compiler auf einem Motorola 68000 (1979) macht das gerade mal 4 Taktzyklen aus. Es ist nicht die Aufgabe der Programmierer, sich um solche Kleinigkeiten zu kümmern. Optimierung auf dieser Ebene ist Compiler-Aufgabe. Außerdem wie gesagt das Beispiel ist ein *ZITAT* aus der genannten Quelle und sollte gerade deshalb nicht verändert werden. Und damit die anderen Beispiele sich ausschließlich in Bezug auf die Einrückung unterscheiden, habe ich sämtliche Änderungen wieder rückgängig gemacht.--ChristianHujer 00:41, 7. Apr 2005 (CEST)

Achja, gerade getestet mit gcc ohne Optimierung sowie javac (1.5.0_01): kein Unterschied zwischen i++ und ++i. Es ist also wirklich unsinnig, wegen alten Prozessoren und alten Compilern von vor 20 Jahren auf ++i zu bestehen. Für 99% der Programmierer macht das keinen Unterschied.--ChristianHujer 00:50, 7. Apr 2005 (CEST)

Inhaltsverzeichnis 1 Java Beispiel 2 Noch ein Stil 3 Was hat der Pico-Stil mit lambda-Funktionen zu tun? 4 Signifikate Einrückung

[Bearbeiten] Java Beispiel

Das Java Beispiel ist ziemlich unglücklich:

1. Strings sind per Definition final - es ist unsinnig nochmal final davor zu schreiben
2. Wird kein Argument übergeben würde eine NullpointerException fliegen - besser: if (args != null && args.length != 0) ...

--matrixx 11:49, 17. Jan 2006 (CET)

1. Strings sind nicht final, sondern immutable (oh, da fehlt noch eine Übersetzung von en:Immutable object). Das bedeutet, es kann durchaus sinnvoll sein, Parameter oder lokale Variablen final zu deklarieren, um zu verhindern, dass der Name einen anderen Wert bekommt. Aber die Methode einer finalen Klasse final zu deklarieren ist mit Sicherheit Quatsch, weil redundant.
2. Die NullPointerException ist durchaus eine legitime Reaktion auf die Übergabe von null sein. Eine sehr verbreitete Konvention ist, dass null als Parameterwert nur dann erlaubt ist, wenn das explizit im Methodenkommentar erwähnt ist, anderenfalls verboten. Der aufrufende Code würde also gegen die Schnittstellenvereinbarung verstoßen und zu Recht mit einer Exception bestraft.

Wie auch immer, die finals entferne ich mal, weil sie für das Beispiel irrelevant sind. --jpp ?! 13:29, 17. Jan 2006 (CET)

Bei 1. hast du Recht, das habe ich verwechselt. Was 2. angeht mag deine Antwort allgemein richtig sein, aber bei der main() ? Wenn ich das Programm einfach so aufrufe (ohne Parameter) erwarte ich einfach keine Exception. (Kann man der main() überhaupt 0 Argumente übergeben - also kann args.length jemals 0 sein ?) --matrixx 18:12, 17. Jan 2006 (CET)

Stimmt, für main gelten andere Regeln, hatte ich nicht gleich dran gedacht. Natürlich kannst du ein Java-Programm ohne Argumente aufrufen, dann bekommst du einen Array der Länge 0. Aber du kannst meiner Meinung nach niemals null als Argumente-Array bekommen. --jpp ?! 21:00, 17. Jan 2006 (CET)

Ich muss dem "Das Java Beispiel ist ziemlich unglücklich" in sämtlichen Punkten widersprechen.

Zu final: Wie Jpp schon sagte, hat die final-Deklaration einer Variable nichts mit der Immutability des durch die Variable referenzierten Objekts zu tun. Der Einsatz von final ist guter Java-Stil, weil damit unbeabsichtigte Veränderungen (Klasse: Beerben, Methode: Überschreiben, Variable: Zuweisungen außer der ersten) verhindert werden. Das final vor der Methode war natürlich redundant, da sämtliche Methoden einer final-Klasse implizit final sind. Einige IDEs, wie IntelliJ IDEA z.B., können übrigens vor nicht-finalen Parametern, nicht-finalen nur einmal zugewiesenen Variablen sowie nicht-finalen in equals() und hashCode() verwendeten Instanzfeldern warnen. Mit final passiert einem der klassische Telefonanruf-war-dazwischen-Flüchtigkeitsfehler void setX(T x) { x = x; } statt void setX(T x) { this.x = x; } nicht. Es gibt natürlich auch andere Konventionen, die in solchen Fällen andere Parameternamen vorschreiben, was meines Erachtens nach aber gekünstelt ist und mich an die Ungarische Notation erinnert, welche man ja in den meisten Code Conventions aufgrund der bekannten Probleme längst wieder verworfen hat. Zudem schützt eine Konvention über andere Parameternamen dennoch nicht vor dem Fehler, die Zuweisung versehentlich an den Parameter statt das Instanzfeld durchzuführen: void setX(T newX) { newX = newX; } - der Fehler wird nur etwas offensichtlicher.

Zu NullPointerException: Es kommt auf den Vertrag der Methode an, ob bei Übergabe von null eine NullPointerException ausgelöst wird oder nicht, und das sollte man normalerweise natürlich auch dokumentieren. Für main gilt allerdings eine andere Regel. Es ist garantiert, dass das String[], das main von der VM übergeben wird, immer null ist. Wenn jemand main() direkt aufruft und für "ohne Argumente" null statt new String[0] verwendet, ist er selbst schuld. Für Varargs-Methoden, und ich habe main (bewußt!) als Varargs geschrieben, gelten nochmals andere Regeln. Wird main(final String... args) als main() aufgerufen, also ohne Argument, ist args != null. Probiere einfach mal folgendes Beispiel aus:

public final class Null {
    public static void main(final String... args) {
        method();
        method(null);
        method((String) null);
    }
    public static void method(final String... args) {
        System.err.println(args);
    }
}

Soviel also dazu. Meiner Meinung nach war die Änderung des Code-Beispiels in Reaktion auf diese Diskussion ziemlich übereilt. Ich bitte darum, nochmal drüber nachzudenken. Sollte in ein paar Wochen keine Antwort oder Rückänderung erfolgen, werde ich die Rückänderung selbst vornehmen. --ChristianHujer 21:13, 30. Jan 2006 (CET)

@ChristianHujer beruhig dich bitte wieder - das Problem ist doch geklärt ;). Ich hatte mich mit den finals geirrt und Jpp hat nur das final vor der Methode entfernt - kein Grund zur Aufregung. Ich finde das ganze in einem leicht verständlichen Beispiel nur etwas dick aufgetragen. Eine ganz normale Hello-World hätte es auch getan - dies ist kein Platz um sein Java-KnowHow zu präsentieren. --matrixx 11:08, 31. Jan 2006 (CET)

Und was ist damit, guten Java-Stil statt den durchschnittlichen Schrott zu präsentieren? Deshalb nämlich final in den Beispielen. Jpp hat nicht nur das redundante final vor der Methode, sondern sämtliche finals entfernt. --ChristianHujer 23:36, 31. Jan 2006 (CET)

Ob diese „final“-Deklarationen guter Programmierstil sind oder nicht, ist durchaus umstritten. Es gibt auch eine starke Fraktion, die der Meinung ist, dass dieses Schlüsselwort, wenn es in lokalem Kontext verwendet wird, nur den Programmcode unübersichtlich macht. Nach Meinung dieser Fraktion ist es zwar bei Feldern aufgrund ihrer Lebenszeit sinnvoll und bei Methoden, weil sie Teil der Schnittstelle einer Klasse sind, nicht jedoch bei lokalem Scope, wo es nur zur Einhaltung von Programmierkonventionen dient. Dafür gibt es – nach Meinung dieser Fraktion – bessere Mittel, nämlich Style-Checker, die auch wesentlich mehr können und den Vorteil haben, nicht den Code zu „verschmutzen“. Wenn du unbedingt möchtest, bau es halt wieder ein, aber stell nicht deine Vorlieben als die einzig gültigen hin. --jpp ?! 15:45, 1. Feb 2006 (CET)

Das ist ungefähr so wie die Diskussion um goto. Für die einen ist goto das Salz in der Suppe und ein Verbot eine Einschränkung, für die anderen ist goto "böse". Ich bin für stabilen Code, der auch in der Wartungszeit (mindestens 80% der Produktlebenszeit) stabil ist, also ohne goto, dafür mit viel const und final. Guter Programmierstil orientiert sich meiner Meinung nach an hoher Lesbarkeit, hoher Wartbarkeit und geringer Fehleranfälligkeit. Da denke ich, besser Beispiele, die dem entsprechen, als Freestyle Golfing. --ChristianHujer 20:01, 3. Feb 2006 (CET)

Versteh mich nicht falsch, ich bin weder ein Anhänger von Gotos, noch des Freestyle-Golfings (netter Artikel übrigens). Ich stimme in allen Punkten mit dir überein, bis auf einen: Die Lesbarkeit des Codes wird durch die Verwendung des Schlüsselworts „final“ im lokalen Kontext einer Methode eher gestört als verbessert. In allen anderen Kontexten (Klassen-, Methoden- und Felddeklarationen) halte ich es ebenso wie du für völlig unabdingbar. Aber egal, hier ist der falsche Ort für solche Diskussionen. Du hast Recht und ich hab' meine Ruhe. ;-) --jpp ?! 17:11, 4. Feb 2006 (CET)

Zu Whitesmiths: Einzelne bedinget Statemments, denen eine Alternativoption (else...) folgt, werden genau wie Allman geklammert, siehe auch: http://www.wikiservice.at/dse/wiki.cgi?EinzigWahreArtGeschweifteKlammernZuSetzen (Beispiel verbessert)

[Bearbeiten] Noch ein Stil

Alle gebräuchlichen Stile haben denselben Nachteil: sie setzen Beginn und Ende einer Konstuktion in dieselbe Spalte, so daß das überfliegende Auge intensiv beschäftigt ist, beides auseinanderzuhalten.

Dieses pinzipielle Problem läßt sich durch Einrücken des schließenden Elementes vermeiden, so daß nur noch das öffnende "ins Auge springt".

Beispiel 1:

<table>
     <tr>
          <td>
               Zelleninhalt
               </td>
          <td>
               Nächste Zelle
               </td>
          </tr>
     <tr>
          <td>
               Zelle in neuer Zeile
               </td>
          </tr>
     </table>

Beispiel 2:

int f(int x, int y, int z)
{    if (x < foo(y, z))
     {    haha = bar[4] + 5;
          }
     else
     {     while (z)
           {     haha += foo(z, z);
                 z--;
                 }
           return ++x + bar();
           }
     }

Die Struktur dieses Stils läßt sich, wie ich meine, wesentlich leichter erfassen, weil das Auge sich dabei - wie bei gegliederten Lesetexten - vom Beginn einer Teilstruktur zum Beginn der nächsten "hangeln" kann. Segantini 14:53, 7. Dez. 2006 (CET)

Ist das deine Meinung oder hat dieser Stil einen Namen ? Der Stil hat nämlich einen großen Nachteil: Man übersieht das End-Tag. Besonders bei HTML/XML vergisst man schnell mal das abschliessende Tag - durch die Einrückung fällt dies aber nicht mehr auf und man sucht sich dämlich. --matrixx 21:01, 7. Dez. 2006 (CET)

Ich finde diesen Stil, wie auch den Horstmann-Stil, auch eher unübersichtlich. HTML-Code formatiere ich zuweilen (wenn ich Zeilen sparen will) eher so (Einrückungstiefe bei HTML nur zwei Leerzeichen, weil da sehr oft sehr tief geschachtelt wird):

<table>
  <tr>
    <td>
      Zelleninhalt
    </td><td>
      Nächste Zelle
    </td>
  </tr><tr>
    <td>
      Zelle in neuer Zeile
    </td>
  </tr>
</table>

--Tobias 15:58, 9. Dez. 2006 (CET)

[Bearbeiten] Was hat der Pico-Stil mit lambda-Funktionen zu tun?

Der Überschrift vermag ich wenig hinzuzufügen...

Lambda-Funktionen sind in Python einfache Funktionen, die lediglich aus (optionalen) Argumenten und einem Ausdruck bestehen, somit also keinerlei Schleifen, bedingte Anweisungen usw. enthalten. Eine Verbindung zum Pico-Stil erschließt sich mir nicht.--Tobias 15:25, 9. Dez. 2006 (CET)

[Bearbeiten] Signifikate Einrückung

Ein interessanter Hinweis wäre noch, daß z. B. die Programmiersprache Python sich der ganzen Diskussion um Einrückungsstile entzieht, weil sie (zur Strukturierung) keine geschweiften Klammern verwendet, sondern die Einrückung selbst signifikant ist; eine m. E. absolut geniale Lösung. Das GNU-Beispiel würde in Python wie folgt aussehen:

def f(x, y, z):
    if x < foo(y, z):
        haha = bar[4] + 5
    else:
        while z:
            haha += foo(z, z)
            z -= 1
        x += 1
        return x + bar()

Die Einrückungstiefe wird von der Sprache nicht definiert; die Einrückung muß allerdings konsistent sein, sonst tritt ein Syntaxfehler auf (und das Programm wird gar nicht erst übersetzt). Als Tabulatorbreite werden 8 Zeichen angenommen. Für Editoren wie vim kann man die allgemein übliche Konvention in einem Kommentar als # vim: sw=4 sts=4 ts=8 festlegen.

Btw, gibt es wirklich (und gab es jemals!) Programme, die stur jeden Tabulator unabhängig von der Position zu einer festen Anzahl von Leerzeichen expandieren??? --Tobias 15:47, 9. Dez. 2006 (CET)