gudn tach!

Womit rueckt Ihr denn eigentlich ein, mit TABS oder Blanks ?

in </archiv/2006/5/t130464/#m843291> haben da verschiedene leute mal ihren senf dazugegeben.
wenn ich die wahl habe, verwende ich 2-column-indent mit tabs. wenn die richtlinien n spaces verlangen, dann verwende ich entweder trotzdem tabs und stelle eben auf n-column-indent und lasse am schluss ein
  :%s/\t/  /g
darueberlaufen, oder ich nutze eben die spaces und stelle vim so ein, dass man den unterschied nur merkt, wenn man sich mit dem cursor darueberbewegt.

prost
seth

Hi,

nein, ich würde nie etwas gegen meine eigene Überzeugung empfehlen, sondern unabhängig vom Thema generell das, was *ich* auch gut finde

diese Ansicht finde ich kontraproduktiv. Wenn mich jemand um eine Browser-Empfehlung bittet, so lautet meine Antwort i.d.R. "Firefox", obwohl ich persönlich mit dem Teil überhaupt nichts anfangen kann. Meinen Liebling Mozilla bzw. Seamonkey würde ich hingegen nur den wenigsten ans Herz legen. Grund: Ich weiß, dass Firefox für die meisten Leute einfach der beste Browser ist. Es ist völlig unerheblich, was ich persönlich am liebsten nutze - denn meine Präferenzen nützen ausschließlich mir etwas.

Auch wenn ich weiß, dass ich mich mit meiner Meinung in einer Minderheit wiederfinde. Und es kommt auch immer mal wieder vor, dass dann jemand sagt, "hey, hast eigentlich recht, geht viel besser", gerade *weil* die Menschen nicht alle gleich empfinden.

Um Minderheiten geht es hier nicht, sondern darum, was für einen Menschen am empfehlenswertesten ist. Und das ist, wenn er selbst sich nicht eine entsprechende Meinung bilden kann (oder will) und es keine wirklich *guten* Gründe für etwas anderes gibt, per se das, was allgemein empfehlenswert ist.

Wenn ich einen Rat oder eine Meinung hören will, um daraus etwas für mich Günstiges abzuleiten, ist mir ja schließlich auch egal, ob ein bestimmter Vorschlag nun Mainstream oder Individualistentum ist - wichtig ist, dass er für *mich* taugt.

Richtig. Und sofern es nicht die o.g. guten Gründe gibt ist das was? Genau :-)

Cheatah

Hi,

nein, ich würde nie etwas gegen meine eigene Überzeugung empfehlen, sondern unabhängig vom Thema generell das, was *ich* auch gut finde (und andere Möglichkeiten höchstens mit erwähnen).

Ich stimme Cheatah absolut zu!

Jeder gute Berater/Verkäufer/... wird/sollte seinem Gegenüber nicht das empfehlen, was er selbst für gut hält, sondern das, von dem er ausgeht, das es für sein Gegenüber empfehlenswert sei. Das kann im Zweifel auch diametral zu den eigenen Vorlieben stehen.

Gruß, Cybaer

Wichtig bei den Begrenzerdingens ist nur, dass man die Blöcke erkennt;

Sehe ich auch so. Der intellektuelle Forumsnutzer würde vielleicht von Logikebenen schwätzen, aber zum Glück sind wir beide ja nicht dementsprechend veranlagt.

Allerdings, allerdings wurde Dein Vorschlag bereits vorausschauend weiter oben als trollig bezeichnet vom werten Herrn Tepasse.

if (bla)
   befehl;
   befehl;
elseif (blubb)
   befehl;
   befehl;
else
   befehl;
endif

ist doch supi. Wer braucht da Klammern.

Ist mir - wie bereits geschrieben - nicht unsympathisch. Allerdings finde ich Klammern gut, z.B. als Bedingungsbegrenzer (Ausdrucksbegrenzer) oder auch bei Blöcken, LOL.

-- Hamster

Hallo Thomas,

Mein Fehler: gilt nur für anonyme Funktionen:

Ähm nein. Es gilt nicht. Alles was Herr Crockford da schreibt sind nur Konventionen für Javascript-Quellcode, die er selbst für sinnvoll erachtet. Das ist keine allgemeingültige Spezifikation im Sinne von »gelten«, sondern eine private Konvention, die man benutzen kann, aber nicht muss.

Abgesehen davon sind Code-Konventionen natürlich sinnvoll.

Tim

Wäre doch schön, wenn im Hintergrund schön validiert wird und in einem Fensterchen Syntaxfehler aufgelistet werden, die man gelegentlich bearbeitet.

Gute Editoren/IDEs schaffen das doch auch so?

Na gut. Aber "mit XML" wäre es cooler.

Eine Funktion sollte zudem seine Anweisungen mit Anweisungsblockbegrenzern umschranken.

Warum das?

Ich argumentiere wie folgt:

• das Umschranken von Anweisungsblöcken (bspw. wenn diese bedingt ausgeführt werden) ist ohnehin erforderlich, das Blockende muss ja erkannt werden
• eine Funktion ist ein Anweisungsblock

Das scheint mir einfach, also folgerichtig.

Klar, manche könnten jetzt meinen, dass der Zeilenvorschub/Wagenrücklauf ja die Eindeutigkeit besorgen könnte(meinen Kommentar dazu kennst Du).

Andere könnten meinen, dass der Funktion mit ihrem unumschrankten Anweisungsblock ja immer eine weitere Funktion folgt (bzw. gar nichts mehr - das scheint mir Deine Python-Argu zu sein). Das ist zwar eine Spur logischer, aber "I am not vonvinced.".

In diese Thematik spielt auch der Anweisungsbegrenzer hinein (bspw. das nette ";" in COBOL, PHP und Perl). Dieser ist _oft_ nicht erforderlich und ich habe mich in jungen Jahren sogar bemüht auf ihn zu verzichten (um Tastendrücke zu sparen ;), es ist aber dennoch verfehlt auf diesen zu verzichten.

Für mich ist Variante 1 ganz klar die übelste (und populärste).
Für mich ist Variante 1 ganz klar das Optimum. Sie ist populär, somit ist man dran gewöhnt.

Du, man ist auch an die populäre SPD gewöhnt.

Sie nutzt den Platz optimal aus. Ist übersichtlich da zusammengehöriges auch zusammen steht und neue Teile (das elsif und das else) optisch durch eine (Nahezu-)Leerzeile abgetrennt ist.

Aber die Blockbegrenzer (in diesem Fall die geschweiften Klammern) stehen neben einer Bedingung.

Kopieren von Code wird schwieriger.
Das mußt Du mir mal erklären.

Man kann die Blöcke nicht so gut "anfassen".

Es gibt noch ein wichtiges Argument gegen "Variante 1", stellen wir uns einfach mal vor die Blockbegrenzer heissen 'BEGIN' und 'END' (sowas soll es auch geben), dann geht "Variante 1" nämlich gar nicht mehr. D.h. Variante 1 geht nur mit manchen Programmiersprachen, Variante 3 (mit sauber horizontal und vertikal abgesetzten Blockbegrenzern) immer.

Variante 2 ist indiskutabel da man ein if ohne Klammern nicht in der Form schreibt; das heißt dann:  ;-)
print "negative" if $x < 0;

War ja Pseudocode.

Variante 3, Deine präferierte, finde ich suboptimal da sie verschwenderisch mit dem, vertikal zur Verfügung stehenden Platz umgeht und den Leser unnötig früh zum Scrollen zwingt. Zudem fügt sie visuelle Stolperfallen ein, wo keine hingehören. Das >>print "negative";<< gehört nun mal direkt zum "if".

Mag sein, aber "Variante 3" ist die Einfachste, d.h. sie kommt mit den wenigsten Regeln aus. Zudem hat sie mir schon wertvolle Dienste bei der Codebesichtigung geleistet, was ich von "Variante 1" (und fremden Code) nun wirklich nicht sagen kann. Gerade die Leute, die "auf einmal" meinen, dass irgendwas zu irgendwas gehört und dabei neue Regeln aufstellen, haben es mir nicht immer leicht gemacht.

Aber wie schon gesagt: Im wikipedia Artikel der hier im Thread bereits verlinkt ist, ist das alles schön zusammengefßt und diese Diskussion ist eigentlich müßig.

Wichtig ist mir, dass meine Argumente verstanden werden. Was Wikipedia da schreibt, ist sowieso eher lau.

3.Fall: geschweifte Klammern mit helfender (ergonmischer) Wirkung:

if ( $x < 0 )

{
    print "negative";
    }
elsif ( $x > 0 )
    {
    print "positive";
    }
else
    {
    print "zero";
    }

>   
> Es mag einfach die Macht der Gewohnheit sein, aber ich finde diese Variante um einiges unübersichtlicher als die "populäre" Schreibweise.  
  
Bin überrascht.  
  

> Mein Auge sucht bei geschweiften Klammern automatisch, wozu dieser Block jetzt gehört, was auf einen Blick erkennbar ist, da die schließende Klammer auf der gleichen Höhe steht wie der zugehörige Ausdruck.  
  
Du kannst Dir vorstellen, dass meine Augen immerhin nur vertikal suchen müssen, da die öffnenden und schliessenden Klammern mit gleichem "X-Wert" kommen?  
  

> Die Blöcke im obigen Beispiel hingegen sehen irgendwie losgelöst aus. Gefällt mir nicht.  
  
"Irgendwie losgelöst"?!  
  
Die sind optisch optimal abgesetzt!

Hi,

ja, eigentlich volle Zustimmung. Die Sache ist aber so, dass ich massenweise Code gesendet bekomme, den ich korrigieren soll (ist halt auch mein Job). Die meisten Fehler bestehen im Umgang mit Datentypen.

Das liegt dann aber meist nicht an den verwendeten Variablennamen, sondern daran, daß die verwendete Sprache keine strenge Typisierung hat.

Ein Beispiel (nur getippt):
dim DateiName as string
DateiName = GetopenFilename(irgendwas)

Daraufhin erscheint ein Dialogfeld, in dem man eine Datei wählen kann. Wird aber auf 'Abbrechen' geklickt, wird FALSE zurückgegeben. Und das ist ja kein String. Es kommt zu einem Fehler, den man leichter erkennen würde,

wenn die Sprache eine strenge Typisierung hätte.
Dann käme es nämlich zu einer passenden Fehlermeldung, bevor das Programm losläuft, nicht erst, wenn zufällig mal ein User auf Abbrechen klickt.

cu,
Andreas

gudn tach!

vom mainzer karneval haben die hessen tatsaechlich weniger ahnung (als z.b. die mainzer). aber die hessen feiern ja auch fassenacht.

Wie kannst DAS den Hessen nur unterstellen. In Hesse feiert ma "Fassenet" !

ich praezisiere: so in der mitte von hessen (wetzlar bis lich) bis nach frankfurt (siehe auch link in meinem letzten posting) spricht man meiner erfahrung nach nur von der fassenacht (oder eben fastnacht). den begriff "fas(se)net"/"fas(se)nedd" habe ich bisher eher von badenwuerttemberglern (jedenfalls noch nicht von hessen) gehoert. wo sagt man das in hessen?

aber klar, dialekte aendern sich von dorf zu dorf. dort wo ich bisher die meiste zeit lebte, hat man im umkreis von nur wenigen kilometern zu zucker "zaker", "zekker" oder "zokker" teilweise mit/ohne rollendem "r" gesagt.

prost
seth