Diskussion:Einrückungsstil

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)

Allerdings ist die Prefix-Syntax einfacher zu verwenden, wenn man Operatoren ueberladet. -- Davidkra 19:29, 19. Jul. 2009 (CEST)

Achtung i++ und ++i haben eine verschiedene Bedeutung. i++ liefert den alten Wert zurück, und ++i den Neuen.

#include <stdio.h>
int main(argc,**argv)
{
 int a,b,c,d;
 b=a=5;
 c=a++;
 d=++b;
 printf(" %d %d\n",c,d);
 return 0;
}

liefert 5 6 zurück. --79.225.117.236 00:03, 17. Jul. 2016 (CEST)

Grundsätzliches

M.E. kann (besser: sollte!) der Beitrag sinnvoller strukturiert werden:

1. Teil: Einrückung als Element der Syntax von Programmiersprachen, um die Blockstruktur einfach zu kodieren

Zunächst ist zu bemerken, dass bereits 1965 von Peter Landin vorgeschlagen wurde, die Einrückung als syntaktisches Element einzuführen -- dieser Vorschlag wurde mit der Programmiersprache ISWIM (»If you See What I Mean«) realisiert, wurde aber nicht in ALGOL 58 oder ALGOL 60 aufgenommen.

Unter den heute verbreitet verwendeten Programmiersprachen enthält namentlich die Programmiersprache Python die Einrückung als syntaktisches Element. Auch Haskell arbeitet mit syntaktisch vorgeschriebener Einrückung. Dann haben syntaktisch korrekte Programme in diesen Programmiersprachen immer eine vernünftige Einrückung -- die Einrückungstiefe (= Anzahl der Leerzeichen oder auch die Expansion des Tabulatorzeichens) ist allerdings syntaktisch nicht exakt vorgeschrieben.

Hier könnte m.E. ein Beispiel folgen.

2. Teil: Einrückung zur zusätzlichen optischen Unterstützung der synataktisch bereits vorgenommen Blockstrukturierung

Die Programmiersprache ALGOL wurde entwickelt, damit Quellcode publiziert werden konnte. Daher kam der Doppelcodierung der Blockstruktur einmal durch Begin-End-Konstrukte und zum anderen durch das typographische Element der optischen Einrückung eine besondere Bedeutung zu.

Folgesprachen der ALGOL-Familie behielten diese Doppelkodierung der Blockstruktur bei.

hier Beispiele: ALGOL 58/60 Simula 67 ggf. ALGOL 68 Pascal Modula-2 Oberon

-- L. Humbert Fr 30. Jul 15:04:55 CEST 2010 (nicht signierter Beitrag von 91.40.169.249 (Diskussion) 15:05, 30. Jul 2010 (CEST))

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)

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)

Die Wikipedia soll neutral sein, also wird der Stil auch aufgenommen. Einen Namen hat er natürlich auch: Banner Style. --ChristianHujer 01:08, 3. Jan. 2007 (CET)

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)

Das ist eine Übersetzung aus dem Englischen Wikipedia-Artikel. Ich habe den entsprechenden Teil gelöscht. --ChristianHujer 01:10, 3. Jan. 2007 (CET)

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)

Ja, solche Editoren gab es tatsächlich, ich habe in den 80ern mal mit solchen Editoren gearbeitet. Leider kann ich mich nicht mehr an einen Namen erinnern. --ChristianHujer 01:20, 3. Jan. 2007 (CET)

Ich halte die folgende Passage unter Verwendung_von_Tabulator_oder_Leerzeichen für rein theoretische Gedankenspiele:

„Gegen eine Verwendung des Tabulators spricht zusätzlich noch das unterschiedliche Verhalten unterschiedlicher Programme in Bezug auf das Tabulatorzeichen. Einige Programme ersetzen das Tabulatorzeichen einfach durch eine eingestellte Anzahl von Leerzeichen (meist 8), während andere Programme am Tabulatorzeichen auf die nächste ohne Rest durch 8 teilbare Spalte auffüllen, was zu unterschiedlicher Darstellung führen kann.“

Solange nicht jemand Beispiele (heute noch!) real existierender Editoren anführt, die das wirklich tun, gehört diese Passage einschließlich der beiden folgenden Beispiele IMO ersatzlos gestrichen. Und selbst wenn es den einen oder anderen Exoten geben sollte, dürften diese eine krasse Außenseiterposition innehaben, was dann auch so formuliert gehören würde. --Tobias 04:36, 9. Apr. 2007 (CEST)

habs mal entfernt. Ich fand den Abschnitt auch unpassend und solange kein verbreiteter Editor so handelt, gibt es auch keinen Grund, das zu nennen −Nachtgestalt ^»D'B'±« 14:51, 29. Jul. 2009 (CEST)

Vorteil von Tabulator nur führend

Der Artikel ist zwar recht neutral, was Tabulatoren angeht, spricht jedoch immer nur von den Problemen. Es sollte aufgeführt werden, dass Tabulatoren, die nur zur Einrückung am Anfang einer Zeile für die Blocktiefe genutzt werden, keinen Problem darstellen. Jeder Programmierer hat dadurch die für ihn eingestellte Einrückung, ganz im Gegensatz zu Leerzeichen, wo eine Einrückung anderen aufgezwungen wird (Arbeit im Team). Für alles andere sollten Tabulatoren, wie bereits im Artikel mit Beispiel gezeigt, nicht genommen werden. --anonym 16:02, 5. Nov. 2007 (CET)

Das gilt nur, solange ausschließlich Tabulatoren verwendet werden. Das sagt der Artikel auch so. Eine Mischung führt zu Problemen. Außerdem raten die meisten Code Conventions (SUN, Linux, GNU etc.) von der Verwendung des Tabulator-Zeichens ab. Was übrigens der Grund dafür ist, warum ich die Änderung von Revolus rückgängig gemacht habe - die Aussage bezüglich des Abratens lässt sich nämlich bestens mit Quellen belegen.

Dass der Artikel nur von den Problemen spricht, stimmt auch nicht. Zitat: "Für eine Einrückung mit Tabulator spricht, dass sich jeder Entwickler selbst die Tabulatorschrittweite einstellen und somit seine persönliche Einrückungstiefe bestimmen kann." --ChristianHujer 11:31, 28. Mär. 2008 (CET)

ich denke, er meint so was (ein Punkt ist ein Leerzeichen, ein Punkt gefolgt von Leerzeichen ein Tab):

void foo()
{
.   cout.<<."a"
.   .....<<."b"
.   .....<<."c".<<.endl;

.   while.(.true.)
.   .   foo();
}

hier wurde eine Tab-Weite von 4 genutzt. Öffnet sie ein User mit 8 und werden nur Leerzeichen verwendet, sieht es so aus

void foo()
{
    cout << "a"
         << "b"
         << "c".<< endl;

    while ( true )
        foo();
}

also genauso. Verwendete er nur Tabs, sieht es so aus:

void foo()
{
        cout << "a"
                << "b"
                << "c".<< endl;

        while ( true )
                foo();
}

auch unschön, vor allem, wenn man Leerzeichen zur Strukturierung verwendet hat.

und jetzt das obige Beispiel:

void foo()
{
        cout << "a"
             << "b"
             << "c" << endl;

        while ( true )
                foo();
}

also genau so, wie es sein sollte. −Nachtgestalt ^»D'B'±« 15:00, 29. Jul. 2009 (CEST)

Das Beispiel demonstriert sehr schön, was gemischter Stil ist und welche Probleme man damit bekommt. Natürlich muß der Code so geschrieben sein, daß alle zusammengehörigen Elemente auf die Verschiebung reagieren. Und das ist im obigen Beispiel für das erste eben nicht der Fall. Ich würde den Schnipsel so anlegen:

void foo()
{
        cout
             << "a"
             << "b"
             << "c" << endl;

        while ( true )
                foo();
}

-- Segantini 08:59, 30. Jul. 2009 (CEST)

Bekannt? Bei wem?

"Bekannte Einrückungsstile", so, wie es aussieht, könnte ich dann morgen meinen eigenen erfinden und auch einfach unten drunterschmieren? Schlage vor, ersatzlos streichen, da TF-/TE-Verdacht.
-- Tuxman 07:26, 12. Jul. 2009 (CEST)

Hallo Tuxman, Also den Absatz komplett zu löschen finde ich zu Hard. Einige der Stile habe sich etabliert. Ich muss je nach Projekt in dem ich Arbeite immer wieder meienn Stil anpassen. 1TBS und Allmann begegnen mit Täglich. Das der "Java" Stil auch seine Berechtigung hat ist Selbsterklärend duch die grösse der Sprache Java. Nebenbei ist mir der Verstoss gegen WWNI und WP:TF nicht klar. Grösstenteils sind die Stile etabliert. Daher bin ich füs rückgägngig machen der Löschen und (falls nötig) Verbesserung des Absatzes. --Axji 13:39, 13. Jul. 2009 (CEST)

Dass die Stile "etabliert" sind, wäre noch nachzuweisen.
-- Tuxman 15:20, 13. Jul. 2009 (CEST)

Ich als Applikationsentwicker sehe da sehr Wohl eine Etabliertheit. K&R ist von den C "Erfindern" , Stroustrup ist Designer von C++ und Java/Sun ist mehr als Selbsterklärend. Allman triffst man fast an jeder Hochschule. Ich hab ein paar Jährchen an einer unterrichtet. GNU Bedarf unter Informatikern auch keiner weiteren Erklärung. Horstmann, Whitesmiths, Pico und Banner über diese würde ich Disskutieren (ich weiss nicht wie verbreitet Pico als Sprache ist. Daher mein Vorschlag: Rückgängig machen der Änderungen und dann Nur die Stile Löschen die nicht ganz so bekannt sind. --Axji 16:25, 13. Jul. 2009 (CEST)

In welcher Einheit misst du denn die Bekanntheit, und ab wie viel Bekanntheit sind sie "etabliert"?

Und, vor allem, was macht die verschiedenen Stile, die ja nun mehr oder weniger willkürlich erfunden wurden, enzyklopädisch ausreichend relevant?
-- Tuxman 18:02, 13. Jul. 2009 (CEST)

Ich habe das Kapitel wieder eingefügt da die Fleissigen Wikipedianer schon anfingen den Artikel anzupassen. Falls du Teile für unrelevand hällst melde dich doch bitte zuerst auf der Diskussionseite. Evtl sehen das einige gar nicht so anders als du. Also wenn die Sprachen als Defacto Standart für ein oder mehrere "Systeme/Bereiche" gelten würde ich das als Relevand bezeichnen. C für jede art von Betriebssystem; C++ als einer der Durchbrüche von Objektorientiertheit. Java Portabilität oder kann dein Handy kein Java? Jede Dieser Sprachen hat einen ganz Speziellen Stil geprägt. Mal abgesehen davon das die GNU-Gemeinde auch einen eigenen Stil hat. --Axji 00:09, 14. Jul. 2009 (CEST)

Es geht hier nicht um die Sprachen! Lies bitte noch mal meine Begründung. Ich setz es mal zurück...
-- Tuxman 00:17, 14. Jul. 2009 (CEST)

Hallo Tuxman, langsam habe ich das Gefühl das du nicht diskutieren willst. Du geht auf keines meiner Argumente ein. Das es Weltweit X Tausend Programierer gibt die sich zu grossen auf die wichtigsten Stile (Siehe was du gelöscht hast) beschränken ist kein Argument oder? Weiter bin ich mir sicher das du meinen Kommentar von bitte nur Teile zu Löschen nicht gelesen hast.Leider geht es hier um Sprachen denn fast jeder "Spracherfinder" hat einen eigenen Stil geprägt. Fast-Jedes Moderne Betriebssystem Basiert auf C und damit auf den dazu geprägten Stile. K&R ist das beste beispiel dafür. 1TBS ist der stil von UNIX/LINUX Kernel schon allein das reicht meines erachtens für eien Erwähnung in Wikipedia. Die Einrükungsstile sind wie Religionen => Es ist keine Theroriefindung sondern verschiedene Ansäte. Erlaube mit die Frage, ich arbeite als Applikationsentwickler, wie ist deine "Verbindung" zu Quellcode? Daher mein Vorschlag wieder Herstellen und auf der Disskusionsseite vor dem Löschen klären was unwesentlich ist. Falls das hier dann doch kein Ende Findet bleibt mir immernoch die Möglichkeit auf die Englishe Wikipedia zu verlinken, oder willst du den Artikel auch Löschen? Grüsse --Axji 14:59, 14. Jul. 2009 (CEST)

Ich will erst diskutieren und dann irgendwelche Grütze in den Artikel schmieren, nicht andersherum. Doch, ich habe deinen Kommentar gelesen, aber Einrückungsstile sind Geschmackssache und keinesfalls "standardisiert". Die Verbreitung mancher Stile hätte ich dann gern mal mit Quellen belegt gesehen, bevor du sie wieder reinschreibst; immerhin ist der Linuxkernel auch nur eine Software! - Ich bin selbst Entwickler, und ich rücke je nach Tageslaune ein. Würde dennoch nie behaupten, ich hätte einen eigenen "Einrückungsstil"!
-- Tuxman 15:05, 14. Jul. 2009 (CEST)

Leider ist die Verbreitung von dem Stilen nur schwer zu beweisen. Die meiste Software ist Closed source. Für alle Gnu Projekte gild. Der Gnu Standart auch wenn dieser nicht immer eingehalten wird. http://www.gnu.no/software/software.de.html (Also Kleiner auszug von Gnu Projekten unten auf der Seite). Der Einrückungsstiil bei mir ist Auf K&R oder 1TBS festgelegt. Je nach Projekt und wird natürlich von meinem Arbeitgeber für mich und die Andren 50 Tausend mitarbeiter so geregelt. (kein panik sind nicht alle 50K Informatiker). Wo du weitere Hinweise finden kannst ist auf http://en.wikipedia.org/wiki/Indent_style auch ganz unten. Aber Achtung steht die gleiche "Grütze" die du aus dem Deutschen Artikel gelöscht hast. Falls du konsequent sein willst lass den ganzen deutschen Artikel löschen. Wen interessieren schon ob ich 2,4 oder 8 Leerzeichen oder gar Tabulatoren benutzte. Leider muss ich sagen das meine Motivation nach einer Aussage wie "Ich bin selbst Entwickler, und ich rücke je nach Tageslaune ein" absolut minimal ist. Arbeitest du in keinem Entwicklungsteam? Ist eure Source-Verwaltung so gut das die Änderungen am Stil nicht als Diff anzeigt? - Vermute das wir beide keine Einigung erreichen werden. Also ist es für mich der Aufwand nicht wert. Lass den Artikel so wie er ist. Ich verlinke das Zeug nun auf der englischen Wikipedia. Grüsse von Entwickler an Entwickler --Axji 15:43, 14. Jul. 2009 (CEST)

Nein, ich arbeite derzeit tatsächlich nicht im Team; bzw., genauer gesagt, in einem einzigen Team. In ebendiesem Team ist es aber Konsens, dass es wurscht ist, wie die Klammern gesetzt werden, so lange der Code leserlich bleibt. In der en.WP wird meiner Ansicht nach tatsächlich zu viel Unsinn geduldet, aber das ist ja nicht Gegenstand dieser Diskussion.

Du gibst mir immerhin Recht: auch wenn dieser nicht immer eingehalten wird - eben! De facto kann also auch in Projekten mit so genannten "Standards" letztendlich jeder frei nach Tageslaune seine Klammern setzen. Was soll also das ganze Prozedere? Der Versuch, irgendwelche Einrückungsstile benennen und standardisieren zu wollen, ist arg praxisfern.
-- Tuxman 17:48, 14. Jul. 2009 (CEST)

Von wegen praxisfern! Selbstverständlich wird von einem freien Entwickler erwartet, daß er den hausüblichen Indent Style verwendet. Als dieser Artikel noch vollständig war, konnte man diese Stile hier recherchieren und wußte dann, wovon der andere spricht. --Segantini 08:04, 15. Jul. 2009 (CEST)

Mag sein, aber dies zu dokumentieren ist die Aufgabe eines Programmierhandbuchs und keiner Enzyklopädie. Tuxman 15:47, 15. Jul. 2009 (CEST)

Noch so als Tipp an dich bei uns im Team Wird von den 50 Personen immernoch verlangt das Sie sowhl Allmann als auch 1TBS kennen und Anwenden können. Das mit den Nicht immer einhalten ist leider in der ganzen Welt so. Wieviele Leute kennst du die nie zu Schnell gefahren sind? Aber falls das der Punkt ist lösch doch auch bitte http://de.wikipedia.org/wiki/Autobahn_(Deutschland)#Tempolimit da halten sich sicher Prozentual weniger dran, wenn sie überhaupt wissen das es so was gibt als an die Einrückungsstile. ;) Grüsse von einem sich wieder beruhingenden --194.41.152.158 10:38, 15. Jul. 2009 (CEST)

Toller Vergleich, ehrlich. Tuxman 15:47, 15. Jul. 2009 (CEST)

Tolle Antwort ... hat mich gleich Überzeugt. ;) Hab nur dein Argument wiederlegt. So als ob wir Diskutieren würden --Axji 16:59, 16. Jul. 2009 (CEST)

Ach, das warst du? - Der Vergleich mit dem Tempolimit ist albern, das kann man nicht anders ausdrücken, ohne zu heucheln. Aber zurück zur Ausgangsfrage: Was interessiert's eine Enzyklopädie, was ihr in eurem Team macht? Denk mal globaler. Oben steht, dass diese "Standards" keine Standards sind und nicht mal in den Gruppen, die sie "erfunden" haben, konsequent durchgesetzt werden. Also was soll das dann?
-- Tuxman 20:44, 16. Jul. 2009 (CEST)

Standarts sind auch Standarts wenn sich nicht allzuviele daran halten. Das war meine Kernaussage. Globaler: Wieso sollte man einen Artikel einrückungsstil haben wenn eines der Zentralen Elemente fehlt. Ich verstehe nicht ganz wieso du Stile die von Grossen Persönlichkeiten oder Betriebssystemen geprägt wurde nicht als Enzylklopädie würdig betrachtest. http://en.wikipedia.org/wiki/The_C_Programming_Language_(book) auch dieses Buch wird als K&R Bezeichnet und hat den Stil mitgeprägt. Siege z.B. hier http://en.wikipedia.org/wiki/K%26R_C#KRC. Von mir aus gehen wird dem in der Deutschen Wikipedia schon jetzt zu wenig beachtung geschenkt. Dagegen stell Sich der stil von Allmann der in der ANSI C Definition bei den Beispielen benutzt wird und daher auch manchmal als "Ansi C" bekannt ist. Whitesmith war einer der Ersten kommerziellen Compiler uns prägte daher seinen Stil. Um nun ganz zum anfang zurückzukehren ja du kannst einen eigenen Stil erfinden aber er wird in Wikipedia erst dann erwähnenswert sein wenn du eine gewisse bekanntheit erreicht hast. z.B. wenn Ansi ihre beispiele in deinem Stil schreibt. Leider habe ich keie Statistiken über die Häufigkeit der benutzung gefunden. In ein paar artikel (siehe Google) wird erwähnt das Allmann der Verbreitetste ist gefogt von K&R/1TBS. Aber leider auch ohne zureichende Quellen. Trotzdem Würde ich schon mal die Beiden sowie den GNU-Stil wieder aufnehmen. Was Hälst du von der Idee --Axji 13:58, 17. Jul. 2009 (CEST)

*nach vorn schieb* Ehrlich gesagt, nicht so richtig viel, da meine Kernfrage immer noch nicht beantwortet ist: Was verleiht diesen Stilen enzyklopädische Relevanz und stellt keinen Verstoß gegen WP:WWNI dar? Die Wikipedia ist kein Programmierhandbuch mit Beispielen, wie man es machen könnte oder wie einzelne Entwickler es machen. So lange Sprachen wie C eine nahezu willkürliche Klammersetzung erlauben, ist es einigermaßen blöde, bestimmte Formatierungen als "Standard" zu bezeichnen. Dass diese Stile von so und so viel Prozent der Programme/Programmierer weltweit genutzt werden, solltest du mit einer Quelle belegen, dann ist das Kriterium erfüllt. Vorher ist es bestenfalls TF ("ist halt so").
-- Tuxman 14:41, 17. Jul. 2009 (CEST)

So lange Kraftfahrzeuge mit nahezu jedem beliebigen Tempo fahren können, ist es einigermaßen blöde, bestimmte Geschwindigkeiten als "Richtgeschwindigkeit" zu bezeichnen. Daß diese von so und so viel Prozent der Autofahrer konsequent eingehalten werden, sollte mal jemand mit einer Quelle belegen, sonst ist der Artikel Richtgeschwindigkeit ein klarer Verstoß gegen WP:WWNI. Mann, Mann. --Segantini 16:14, 17. Jul. 2009 (CEST)

Würdest du vielleicht bitte endlich die absurden Vergleiche beiseite lassen? Das Thema "Richtgeschwindigkeit" ist für jeden Menschen, der das Haus auch mal verlässt, selbst zu Fuß, interessant, während Einrückungsstil nun wirklich kein Thema für die Massen ist. Aber wenn dir so viel daran liegt, kannst du dort gern einen LA stellen. Ich halte dich sicher nicht davon ab.
-- Tuxman 17:02, 17. Jul. 2009 (CEST)

Aha, demnach sind also von 931.106 Wikipedia Artikeln 931.105 ein Thema für die Massen, nur dieser nicht? --Segantini 17:28, 17. Jul. 2009 (CEST)

In der WP geht es nicht nach dem Prinzip "aber die anderen auch!" ...
-- Tuxman 19:47, 17. Jul. 2009 (CEST)

Hallo Tuxman danke fürs nach vorne holen ist viel angenehmer zu lesen. Aber Klammersetzung ist kein "Programmierhandbuch" sondern eher die Pinselführung eines Malers. Es gibt verschiedene Methoden und die sind sicher einer Erwähnung in der Wikipedia wert. Auch wenn nur ganz wenige leute jemals den Stil eines DaVinci oder Dali erreichen werden. Auch glaube ich dass in der "modernen Welt" Kunst bei der grossen Masse immer mehr an Bedeutung verliert. Trozdem würde ich keinen Artikel über einen Kunststil missen wollen. Ähnlich habe ich es mit den Leuten hinter den verschiedenen Klammersetzungen. Sas waren/sind ganz grosse in ihrem Fach. Oder sagt dir der Name Stallmann nichts? Daher ist auch der Stil dieser Person erwähnenswert. Grüsse --Axji 22:18, 17. Jul. 2009 (CEST)

Natürlich sagt mir der Name Stallman was. (Auch, wenn ich Emacs persönlich absolut grausig finde.) Aber sein Programmierstil ist nicht automatisch wichtiger als zum Beispiel meiner. Im Beispiel C wäre eher der Stil von Thompson/Ritchie von Bedeutung.
Auch ein "großer" Programmierer ist nur eine Einzelperson und kann "seinen" Stil frei definieren. Das verleiht ihm noch lange nicht den Status eines "Standards" und schon gar keine enzyklopädische Relevanz. Oder würdest du diese Information bspw. im Brockhaus finden?
-- Tuxman 23:45, 17. Jul. 2009 (CEST)

Also Richie ist das R in K&R damit hätten wir den Stil von einem der Beiden schon mal. Leider ist Ken Thompson nicht das K ;). Aber wenn du den Stil erwähnen willst dann sollte auch Allmann erwähnt werden und wenigstens einen einblick auf die Klammerdiskussion. Ersetze in einem satz mal Programmierer mit Maler/Künstler .... dann wäre der Stil erwähnenswert auch wenns nur einer War. Leider habe ich keinen Brockhaus hier Stehen, der hat sowieso nur 300'000 Schlagwörter da ist mir die Wikipedia lieber, da umfassender. --Axji 08:48, 18. Jul. 2009 (CEST)

Im Brockhaus wird eben nicht jeder noch so nischenfreundlicher Käse aufgenommen, den irgendwer persönlich für sonstwie wichtig hält. Programmierer sind nun mal keine Maler/Künstler, ihre Werke interessieren nach 300 Jahren, nehme ich an, nahezu niemanden mehr. Die Informationstechnik ist nun mal ein kurzlebiges Genre.
-- Tuxman 19:43, 18. Jul. 2009 (CEST)

Kannst du mit ner Niederlage leben? Es gibt im Online Brockhaus ofensichtlich den Passenden artikel. siehe http://www.brockhaus.de/wissen/k&r-c Leider habe ich nicht die Lust den ganzen artikel zu kaufen. => es ist Wert in Enzyklopädien erwähnt zu werden => wiederherstellen. Artikel handelt über das buch das den K&R einrückungsstil Proklamiert und als de-facto standartwerk für C angeschaut wird Gruss --Axji 21:54, 18. Jul. 2009 (CEST)

Oha. (Aber was hat ein Artikel über ein Buch in diesem Lemma verloren?)
-- Tuxman 23:55, 18. Jul. 2009 (CEST)

Tja K&R waren dei Autoren und es war wie schon erwähnt das de-facto standartwerk. K&R hat sich als übernamen für die beiden Autoren, da Buch und den Stil eingebürgert. Mehr darüber findest du hier http://en.wikipedia.org/wiki/The_C_Programming_Language_%28book%29 leider in der Deutschen Wikipedia auch nicht so gut vertreten. Aber in 11 anderen Sprachen ;) --Axji 15:02, 19. Jul. 2009 (CEST)

*schieb* Ja, die en.WP lässt viel als relevant durchgehen, wo die de.WP verzweifeln würde, hätte sie Empfindungen. Nun, ich frage mal andersherum: Wo liegt der konkrete Mehrwert für das Verständnis, was ein "Einrückungsstil" ist, wenn man diese Informationen einfügt? Darum geht's ja - einen Artikel möglichst kurz und einprägsam formulieren.
-- Tuxman 16:13, 19. Jul. 2009 (CEST)

Also meiner Meinung nach ist die Klammersetzung einer der elementaren Teile des Einrückungsstils. Also nicht Mehrwert sondern Kernaussage. Ich stelle mir eher die Frage wieso soll man das Wissen den Leuten vorenthalten? Ok es ist nur für einen kleinen Teil der Menschheit interessant aber trifft das nich auf fast alles zu? -- Axji 10:43, 20. Jul. 2009 (CEST)

Natürlich ist die Klammersetzung wichtig. Aber m. E. genügt da schon ein Satz, der erklärt, dass es verschiedene Möglichkeiten gibt, Klammern in verschiedenen Sprachen zu setzen. Die einzelnen Stile finden auch in weiter führenden Links ausreichend Beachtung.
-- Tuxman 15:33, 20. Jul. 2009 (CEST)

Nein das finde ich nicht dann Wikipedia ist keine Linksammlung. Sowas gehört in den Artikel wenn sich schon ein grossteil der Links damit beschäftigen. Gruss -- Axji 13:40, 22. Jul. 2009 (CEST)

Richtig, keine Linksammlung, aber auch kein Handbuch.
-- Tuxman 15:42, 22. Jul. 2009 (CEST)

Das solls ja auch nicht werden bloss wieder einigermassen vollständig. Wenn ich es jetzt wieder herstelle wirst du es wieder löschen oder kannst du damit leben das einige der Stile Aufgeführt werden? (Sorry aber die Diskussion muss irgendwann ein Ende haben ... hätte in der Zeit schon fast 2 Artikel schreiben können. ;) ) Gruss -- Axji 18:05, 22. Jul. 2009 (CEST)

Um welche konkreten Stile geht es?
-- Tuxman 18:34, 22. Jul. 2009 (CEST)

Eigentlich um Alle, der Vollständigkeits halber aber da ich da wohl auf ner ganz schlechten Verhandlungsposition stehe würde ich die "Grossen" wieder reinnehmen. Aber Am Herzen liegen mit K&R(1TBS), Allmann, Gnu und BSD/Kernel. Horstmann, Pico, Whitesmiths und Banner empfinde ich als weniger Häufig verwendet und daher "unwichtiger". Hoffe nun nicht von der Pico-Gemeinde gehasst zu werden ;) -- Axji 00:11, 23. Jul. 2009 (CEST)

Ich würde es begrüßen, wenn du Einzelnachweise beilegen könntest, die eine gewisse Bekanntheit des jeweiligen Stils zumindest erahnen lassen. (Bücher der Stilerfinder zählen logischerweise nicht, wegen POV.) - Ansonsten wäre das ein Kompromiss, mit dem ich leben könnte. :-)
-- Tuxman 03:58, 23. Jul. 2009 (CEST)

Habe die 4 Stile wieder reingestellt. Werde Abends gleich mal nach den Passenden Nachweisen suchen und hinzufügen. Aber leider werden sich nicht viele Leute um die Verbreitung der Stile kümmern. Ich werde mein Bestes tun -- Axji 10:46, 23. Jul. 2009 (CEST)

Ich hielte es für sehr schade, wenn Name und zugehöriges Beispiel aus dem Kollektivwissen verschwänden und nur noch in irgendwelchen Fachbüchern auftauchten. Für mich ist auch Banner enzyklopädiewürdig, weil er sich in einem wesentlichen, die visuelle Erfaßbarkeit fördernden Punkt von den anderen unterscheidet. Die Fehlersuche mag bei Banner auf den ersten Blick zwar schwieriger wirken, eigentlich passieren diese Art Fehler aber erst gar nicht, wenn man sich konsequent an den gewählten Stil hält. --Segantini 12:41, 23. Jul. 2009 (CEST)

Was ist das denn für eine Begründung? Hat nicht auch Carl Benz das Automobil "willkürlich erfunden"? Wäre dies wirklich ein Löschkriterium, sähe die Wikipedia schon bald so gerupft aus wie meine letzte Weihnachtsgans. -- Segantini 19:03, 13. Jul. 2009 (CEST)

Das Automobil hat weltweite Bekanntheit, auch bei Leuten, die "Computer" noch nicht mal schreiben können. Welch hanebüchener Vergleich.
-- Tuxman 19:28, 13. Jul. 2009 (CEST)

Hanebüchen ist ein Artikel, der mit "Für die Programmiersprache C gibt es vier verbreitete Einrückungsstile" beginnt, und dann kommt ... nix mehr. Keine Namen, keine Erwähnung der Unterschiede, keine Beispiele. "Stell dir vor, gestern habe ich vier Leute getroffen." Punkt, Schluß. Oder wie? -- Segantini 00:30, 14. Jul. 2009 (CEST)

Auch wieder wahr. Der Satz sollte ersatzlos gestrichen oder jedenfalls umformuliert werden. Mach ich gleich mal.
-- Tuxman 02:04, 14. Jul. 2009 (CEST)

Es kann doch wohl nicht sein, dass bei Einrückungsstilen unter C weder K&R noch 1TBS auftaucht? K&R, beschrieben in Kernighans und Ritchies Buch "The C Programming Language", was (immernoch) DAS Referenzbuch auf dem Gebiet ist, kann man durchaus als verbreitet und als Standard bezeichnen. Genauso 1TBS, der gesamte UNIX und LINUX Kernel ist in dem Stil geschrieben. Ergo: Bekannt aus Fachliteratur, vielleicht solltest du selbige konsultieren bevor du hier auf Definitionen von "bekannt" rumreitest und wild interessante und wichtige Fakten löschst. (Ja, Fakten)--89.246.132.23 17:21, 27. Aug. 2009 (CEST)

Na, dem kann ich nur zustimmen. Habe eben mal den Codingstandard des Zendframework in der Linkliste hinzugefügt. Die Jungs haben sich ein paar praktikable Gedanken gemacht, würde ich sagen.Frankxy Freitag mittag, 23.10.2009 (13:13, 23. Okt. 2009 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Och man, Whitesmiths und Pico zu löschen ist doch wieder reine Korinthenkackerei. Nur weil die Überschrift "Bekannt" heißt, wird hier schon wieder die Relevanzdebatte geführt. Wieder ein echter Grund, die englische Wikipedia zu lesen. IMHO sind erstens beide Stile historisch gewachsen und schon damit erwähnenswert. Viel mehr aber noch, um Alternativen zu Einrück-Philosophien aufzuzeigen. Nur weil etwas mehr und mehr Monopolstellung einnimmt, sagt das nichts über die Relevanz von Alternativkonzepten aus. Ich frage mich echt, wen die lange Liste von Stilen - die im Übrigen noch übersichtlicher als jetzt war - nun letztendlich gestört hat. --nik --85.178.210.243 15:40, 31. Okt. 2009 (CET)

EInrückung der return-Anweisung

Warum sind in den Beispielen die return-Abweisungen so weit eingerückt? Logisch betrachtet müsste die return-Anweisung doch innerhalb einer Funktion um nur eine Ebene eingerückt werden!? --Seth Cohen 17:58, 15. Nov. 2010 (CET)

Defekte Weblinks

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://framework.zend.com/manual/de/coding-standard.html
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Problem mit Ressource (HTTP-Statuscode 400)http://giftbot.dwl.invalid/http://framework.zend.com/manual/de/coding-standard.html
• http://www.oracle.com/technetwork/java/codeconv-138413.html
  • Vielleicht ist eine archivierte Version geeignet: archive.org * webcitation.orghttp://giftbot.dwl.invalid/http://www.oracle.com/technetwork/java/codeconv-138413.html
  • Artikel mit gleicher URL: Quelltextformatierung (aktuell)

– GiftBot (Diskussion) 17:03, 20. Dez. 2015 (CET)

West-Coast vs. East-Coast

Warum sind denn K&R und Unix, die in New Jersey aktiv waren, West-Coast, und BSD, das aus Kalifornien kommt, East-Coast? Das muss doch anders rum sein! Ich vermute, es ist ein Fehler. Die Begriffe East-Coast und West-Coast sind mir in dem Zusammenhang auch nicht gelaeufig. Vermutlich sind sie lediglich von Unix/K&R bzw. BSD/Allman abgeleitet, was umso mehr dafuer spricht, dass sie falsch rum sind. Ich will's bloss nicht direkt aendern, weil ich nicht weiss, ob vielleicht noch etwas anderes dahinter steckt, da ich nicht erkenne. --Meillo (Diskussion) 15:16, 13. Jun. 2018 (CEST)

So oder so hätte ich gerne Quellenangaben für diese Bezeichnungen. Ich habe die Bezeichnungen außerhalb der deutschsprachigen Wikipedia noch nirgendwo gehört, aber das hat wohl nicht viel zu heißen. Sie erscheinen beispielsweise nicht im Jargon File und auch nicht in den entsprechenden Artikeln in der englischsprachigen und der französischsprachigen Wikipedia. Jedenfalls standen diese Bezeichnungen schon in der allerersten Fassung dieses Artikels von 2005. -- ~~

Inzwischen habe ich gelernt, dass die Bezeichnung "East const" für die Platzierung des "const" rechts vom Rest des Typdeklarators wohl doch gebräuchlich ist, siehe beispielsweise hier und hier. "East const" ist aber wohl einfach nur ein Wortspiel, eine Verballhornung von "East coast": Das "const" steht rechts, also "östlich" vom Rest des Typdeklarators. Die Bezeichnungen "East const" und "West const" haben wohl nichts mit verschiedenen Kodierungsstilen in New Jersey oder Kalifornien zu tun. (Und es gibt auch "East-End-Funktionen".) -- Tea2min (Diskussion) 10:50, 19. Jun. 2018 (CEST)

Also "Const" und nicht "Coast"? An den Stellen, an denen das im Artikel auftaucht passt das aber inhaltlich nicht, da es da um Einrueckung und geschweifte Klammern geht. In den Beispielen tauchen ja noch nicht mal Definitionen auf. Ich plaediere dafuer, dass die Begriffe "East Coast" und "West Coast" aus dem Artikel entfernt werden, da sie weder gelaeufig sind (ich habe mich immer wieder mit Coding Style beschaeftigt, sie aber nie angetroffen ... die anderen Namen schon), noch im Zusammenhang hier Sinn machen, noch belegt sind, noch einen Informationswert fuer den Artikel bieten. --Meillo (Diskussion) 23:11, 19. Jun. 2018 (CEST)

Ich habe die Begriffe nun aus dem Artikel entfernt. --Meillo (Diskussion) 15:47, 7. Apr. 2019 (CEST)

SL5small-Stil

Ich habe diesen Stil bereits einmal entfernt, da er vollkommen unbekannt ist und keinerlei Relevanz hat. Selbst im Forum der Skriptsprache AutoHotkey ist der Stil zu 99% unbekannt (abgesehen von den entsprechenden Posts der Erfinders). Der "Erfinder" ist offenbar ein Informatiker der auch unter dem Namen SL5 eine werbliche Website betreibt.

Ich entferne diesen Stil nochmals und bitte vor einer eventuellen Revertierung um Belege, die die Relevanz - entgegen meiner Ansicht - belegt. Google liefert auch hauptsächlich nur Wiki-Klone und diverse Nennungen durch den Erfinder selbst. Die bisherigen Belege sind auch nur Links auf das Github-Konto und eine Webseite des sogenannten SL5. Sämtliche relevanten Wiki-Bearbeitungen erfolgten außerdem durch ein Ein-Themen-Konto.

Der Stil hat sich ja nun doch einige Zeit in Wikipedia gehalten - aber irgendwann sollte mit der Eigenwerbung auch mal Schluss sein.--Kramer ...Pogo? 19:10, 26. Mär. 2019 (CET)

Ratliff-Stil Aehnlichkeit

Ich denke, dass der Ratliff-Stil mehr Aehnlichkeit mit dem Whitesmith-Stil hat als mit 1TBS. Er unterscheidet sich von diesem naemlich nur dadurch, dass die oeffnende Klammer nicht alleine steht (allerdings nur in C, nicht aber in HTML, btw. Das HTML-Beispiel scheint mir mehr Whitesmith zu entsprechen als Ratliff). Die groessere Aehnlichkeit zu Whitesmith statt zu 1TBS wird deutlich wenn man sich "else" anschaut. Meiner Meinung nach sollte Ratliff zudem nicht separat sondern als Variante von Whitesmith gefuehrt werden. --Meillo (Diskussion) 15:34, 7. Apr. 2019 (CEST)

• Kann man gerne so machen. Der Stil ist halt unter dem Namen bekannt, aber der Name kann ja auch mit erscheinen. Gruß --Hellerhoff (Diskussion) 15:16, 10. Apr. 2019 (CEST)

Block bei Einzelstatements (K&R vs. 1TBS)

Es fehlt IMO eine noetige Unterscheidung zwischen dem originalen K&R-Stil, bei dem Einzelstatements ohne Block (d.h. geschweifte Klammern) stehen, und 1TBS, wo immer ein Block genutzt wird.

K&R (Bloecke nur da wo sie noetig sind, in diesem Beispiel an keiner Stelle):

int euklid(int a, int b)
{
	if (a == 0)
		return b;
	while (b != 0)
		if (a > b)
			a -= b;
		else
			b -= a;
	return a;
}

1TBS (Bloecke bei jeder Kontrollstruktur):

int euklid(int a, int b)
{
	if (a == 0) {
		return b;
	}
	while (b != 0) {
		if (a > b) {
			a -= b;
		} else {
			b -= a;
		}
	}
	return a;
}

Beim K&R-Stil braucht man die Bloecke nur wenn es sich um mehr als ein Statement handelt oder um das Dangling else-Problem zu loesen.

Bei 1TBS setzt man sie immer, weil die Idee hinter 1TBS ist, dass man Zeilen einfuegen und entfernen kann, ohne, dass man durch die Aktion andere Zeilen nacharbieten muss. Wenn man im obigen Beispiel in eines der "if"s eine weitere Anweisung einfuegt (z.B. eine printf()-Debug-Ausgabe), dann muss man beim K&R-Stil im gleichen Zug auch geschweifte Klammern einfuegen, bei 1TBS aber nicht.

Wenn ich meine Buecher wieder zur Hand habe, kann ich gerne originale Beispiele beitragen. Soweit ich weiss war das nicht nur eine Optimierung fuer den Buchdruck, sondern ist auch im Originalcode von Ken und Dennis so. Das kann man auch nachschauen.

Ich weiss nicht, ob und wann ich dazu komme, diesen Abschnitt zu ueberarbeiten, darum dokumentiere ich das vorerst mal hier. Kommentare und weiterer Input sind willkommen!

--Meillo (Diskussion) 16:25, 7. Apr. 2019 (CEST)