Codekonventionen für Funktions-klammern

[Thomas Schenkeli]

Egal in welche Javascript-Bücher man schaut oder welche Tutorials man liest, immer wird einem folgende Konvention Nahe gelegt:

Funktion() {     //some Code }

Warum nicht:

Funktion() {     //some Code }

??? Ich empfinde Zweiteres als um vieles leichter lesbar. Gibt es einen speziellen Grund warum sich aber Ersteres durchgesetzt hat oder einfach nur weil vor tausenden von Jahren ein Prophet sich dazu entschlossen hat diese Version zu födern?

Danke für eure Hilfe lg Thomas

[Cybaer]

Hi,

Egal in welche Javascript-Bücher man schaut oder welche Tutorials man liest, immer wird einem folgende Konvention Nahe gelegt:

Funktion() {
    //some Code
}

Warum nicht:

Funktion()
{
    //some Code
}

???
Ich empfinde Zweiteres als um vieles leichter lesbar. Gibt es einen speziellen Grund warum sich aber Ersteres durchgesetzt hat oder einfach nur weil vor tausenden von Jahren ein Prophet sich dazu entschlossen hat diese Version zu födern?

Danke für eure Hilfe
lg
Thomas

Gruß, Cybaer

[_roro]

Hi,

alles Gewohnheitssache, je nach Editor. Habe ich den xemacs, rückt der mit dem tab-key

ff()
  {
   // statement
  }

die Schweifies auf eine feste Pos. Habe ich jedoch mein TextPad, kann das auch schon mal so aussehen:

ff()
     {
      // statement
     }

womit manchmal nicht gleich sichtbar ist, wohin die Schweifies gehören.

Daher finde ich die Schreibweise
 ff(){
   // statement
 }
besser, weil Schweifie-"zu" in der gleichen Spalte wie das erste f mir gleich sagt, das gehört zusammen.

--roro

[Cybaer]

Hi,

ich hab doch gar nix gesagt - bin wohl versehentlich auf "absenden" gekommen. =:-)

Gab es nicht früher mal ein "zuviel gequotet - wollen Sie wirklich senden"?

Unabhängig davon ...

Daher finde ich die Schreibweise
ff(){
   // statement
}
besser, weil Schweifie-"zu" in der gleichen Spalte wie das erste f mir gleich sagt, das gehört zusammen.

... stimme ich dem vorbehaltlos zu.

Wenn es anders aussieht, kriege ich persönlich auch rote Pusteln auf der Zornesstirn. Und das stört mich beim Verständnis enorm. ;->

Gruß, Cybaer

[_roro]

Hi,

ich hab doch gar nix gesagt - bin wohl versehentlich auf "absenden" gekommen. =:-)

Und, ich wollte meinen POST eigentlich weiter oben anbringen, war aber schon bei Dir drin.

Gab es nicht früher mal ein "zuviel gequotet - wollen Sie wirklich senden"?

Ja, für die notorischen Deppen. Mich als Gelegenheitsdepp beeindruckt sowas nicht mehr. Hab dann halt die Folgen zu tragen ;-)

Unabhängig davon ...

Daher finde ich die Schreibweise
ff(){
   // statement
}
besser, weil Schweifie-"zu" in der gleichen Spalte wie das erste f mir gleich sagt, das gehört zusammen.

... stimme ich dem vorbehaltlos zu.

Prima. Den xemacs, der automatisch einrückt mag ich überhaupt nicht, ich hab den nur genommen wegen der kollegialen Kompatibilität.

Ansonsten lob ich mir das textpad (XP) und den vi (LINUX), eine Schriftart mit fester Zeichenbreite und alles in s/w.

Viele Grüße, Rolf

[Cheatah]

Hi,

Mich als Gelegenheitsdepp

YMMD :-)

Cheatah

[hkl]

Hallo !

Prima. Den xemacs, der automatisch einrückt mag ich überhaupt nicht, ich hab den nur genommen wegen der kollegialen Kompatibilität.

M-x c-set-style TAB :-)

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

Gruss

Holger

[seth]

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

[hkl]

Hallo seth !

Bin bekennender "tabber" - bei allen Editoren die ich kenne, kann sich der User die tabwidth zur Anzeige ja selbst waehlen.

Bei HTML finde ich's besonders wichtig - z.B. bei table-based layouts stell ich die zum Editieren auf 4 und zum Navigieren auf 2 damit ich Uebersicht zuruckgewinne.

Den "Glaubenskrieg" darum vielerorten versteh ich immer nicht - TABS sind imo unbestreitbar flexibler.

Gruss und schoenen ersten Advent !

Holger

[Der Martin]

Hallo,

Egal in welche Javascript-Bücher man schaut oder welche Tutorials man liest, immer wird einem folgende Konvention Nahe gelegt:
Funktion() {
    //some Code
}

das ist natürlich Gewohnheits- und Geschmackssache. Die obige Schreibweise finde ich persönlich die schlechteste aus einer ganzen Reihe von Varianten. Die öffnende Klammer am Zeilenende zu plazieren, macht den Code IMHO sehr unübersichtlich.

Warum nicht:
Funktion()
{
    //some Code
}

Du sagst es: Warum nicht. Ich finde das übersichtlicher: Die öffnende Klammer steht in derselben Spalte wie die schießende, so dass das Ganze auch optisch einen Block ergibt (vorausgesetzt, man verwendet außerdem Einrückungen zum Gliedern von Blöcken).

Ich empfinde Zweiteres als um vieles leichter lesbar.

Ich auch.

Gibt es einen speziellen Grund warum sich aber Ersteres durchgesetzt hat oder einfach nur weil vor tausenden von Jahren ein Prophet sich dazu entschlossen hat diese Version zu födern?

Sowas in der Art wird vermutlich der Grund sein. Weiß der Geier, was dieser Prophet vorher geraucht hat.

Ciao,
 Martin

[Cheatah]

Hi,

Die öffnende Klammer am Zeilenende zu plazieren, macht den Code IMHO sehr unübersichtlich.

siehst Du, für mich gilt das genaue Gegenteil. Bei dieser Schreibweise ...

Funktion()
{
    //some Code
}

... kann ich nicht mehr auf einen Blick erkennen, wo die Blöcke anfangen bzw. wozu sie gehören. Zudem wird der Code unübersichtlich lang.

Ich empfinde Zweiteres als um vieles leichter lesbar.
Ich auch.

Die meisten mir bekannten Styleguides empfehlen die Variante 1. Ich auch.

Cheatah

[Der Martin]

Hi Cheatah,

Die öffnende Klammer am Zeilenende zu plazieren, macht den Code IMHO sehr unübersichtlich.
siehst Du, für mich gilt das genaue Gegenteil.

so sind die Ansichten verschieden. ;-)

Bei dieser Schreibweise ...

Funktion()
{
    //some Code
}

... kann ich nicht mehr auf einen Blick erkennen, wo die Blöcke anfangen bzw. wozu sie gehören.

Ach. Sie fangen da an, wo die Zeile mit einer öffnenden Klammer beginnt. *Ich* finde das intuitiv.

Zudem wird der Code unübersichtlich lang.

Deswegen schreibe ich die erste Anweisung des Blocks auch gleich in dieselbe Zeile wie die öffnende Klammer:

if (expression)
   { statement;
     statement;
   }

Diese Schreibweise hat sich bei mir von C/C++ her kommend in Jahren als diejenige herauskristallisiert, mit der ich am besten klarkomme.

Die meisten mir bekannten Styleguides empfehlen die Variante 1.

Weiß ich. Ich kann mich aber nicht damit anfreunden und benutze sie daher nicht.

Ciao,
 Martin

[Cheatah]

Hi,

so sind die Ansichten verschieden. ;-)

jau :-)

... kann ich nicht mehr auf einen Blick erkennen, wo die Blöcke anfangen bzw. wozu sie gehören.
Ach. Sie fangen da an, wo die Zeile mit einer öffnenden Klammer beginnt. *Ich* finde das intuitiv.

Ich finde es nicht intuitiv, dass ich zwar erkenne, wo formell der Block beginnt, aber dann noch nach der Zeile suchen muss, die den Block bestimmt. In meiner Programmier-Welt tauchen Blöcke nämlich nicht einfach so auf - ich weiß, dass das in diversen Sprachen geht - sondern haben immer einen Grund, z.B. eine Schleife, eine Abfrage, eine Funktionsdeklaration ...

Zudem wird der Code unübersichtlich lang.
Deswegen schreibe ich die erste Anweisung des Blocks auch gleich in dieselbe Zeile wie die öffnende Klammer:

Boah, das ist nun wieder _ganz_ schlimm. Da beginnen Code-Zeilen an einer anderen Spalte als an der, an der sie beginnen.

Diese Schreibweise hat sich bei mir von C/C++ her kommend in Jahren als diejenige herauskristallisiert, mit der ich am besten klarkomme.

Ja, wie Du schon sagtest: Reine Gewöhnungssache :-)

Die meisten mir bekannten Styleguides empfehlen die Variante 1.
Weiß ich. Ich kann mich aber nicht damit anfreunden und benutze sie daher nicht.

Da ich mit Deinen Codes nicht arbeiten muss, hindere ich Dich nicht daran ;-) Trotzdem solltest Du vielleicht überlegen, ob Du nicht entgegen Deiner persönlichen Präferenz lieber das empfehlen solltest, was eher der allgemeinen Empfehlung entspricht.

Cheatah

[Der Martin]

Hallo,

Trotzdem solltest Du vielleicht überlegen, ob Du nicht entgegen Deiner persönlichen Präferenz lieber das empfehlen solltest, was eher der allgemeinen Empfehlung entspricht.

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). 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. Eine allgemeine Empfehlung mag für eine Mehrheit tatsächlich der Knüller sein, aber es gibt immer ein paar dazwischen, die das anders sehen.

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.

Ciao,
 Martin

[Gunnar Bittersmann]

Hello out there!

Auch wenn ich weiß, dass ich mich mit meiner Meinung in einer Minderheit wiederfinde.

Ich bin gerade dabei, von

foo {  
  bar;  
}

auf

foo  
{  
  bar;  
}

umzusteigen.

Sollte solch „unübersichtlicher“ Code der Grund sein, warum niemand in meinem Thread anwortet?

See ya up the road,
Gunnar

[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

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

[Der Martin]

Hallo,

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.

nein, eben nicht. Damit unterstellst du (möglicherweise unbewusst), dass die Menschen alle gleich empfinden. Und dieser Uniformismus fällt mir in vielen Lebensbereichen unangenehm auf.

Wenn ich einen Rat oder eine Meinung hören will, [...] wichtig ist, dass er für *mich* taugt.
Richtig. Und sofern es nicht die o.g. guten Gründe gibt ist das was?

Dann ist der Rat, den mir der Gefragte gibt, eine Meinung von möglicherweise vielen. Dann kann ich diesen Vorschlag mit anderen vergleichen und dann entweder gut finden oder auch nicht. Das Argument, dass "es allgemein so empfohlen wird", kümmert mich dabei nicht die Bohne, wir sind schließlich alle Individualisten. Du nicht? ;-)

So long,
 Martin

[Cybaer]

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

[Hamstar]

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.

Jeder gute Verkäufer sollte dem Kunden empfehlen das zu kaufen, was zu verkaufen ist. Additiv dazu sollte er Zufriedenheit generieren, was oft mit rein sprachlichen zu bewerkstelligen ist.
KEINESFALLS sollte der Verkäufer das verkaufen, was er für den Kunden für empfehlenswert hält. Und zwar gleich aus mehreren Gründen: 1.) ein Verkäufer soll ganz primär verkaufen was zu verkaufen ist 2.) er soll nicht wirklich schlau werden und sich in die Lage des Kunden hineinversetzen und dessen Interessen antizipieren und vertreten (vortäuschen muss er das unter Umständen, aber er sollte es nicht witrklich tun, zudem kann so auch massive Unzufriedenheit beim Kunden generiert werden, wenn der Verkäufer mehr als das Produkt verkauft, also beratet) 3.) ein Verkäufer kann nur verkaufen, wenn er mehr kann, sollte er Berater werden oder Einkäufer   ;)

Beim Berater/Consultant stimme ich Dir grundsätzlich zu, aber Du weisst auch, dass "Gefälligkeits-Consulting" (der zu Beratende erhält die Beratung mit dem von ihm gewünschten Ziel, nämlich sein bisheriges Wirken in der Firma als wertvoll zu bestätigen) und "Powerpoint-Consulting" (der Beratende wird zugesülzt) überwiegen. Es gibt auch noch "Alibi-Consulting" (Staatsbetriebe sind da anfällig) und "Luxus-Consulting" (der Beratene nimmt bspw. die Beratung als Ideenmenge zur Kenntnis und handelt konträr).

So wie in der Demokratie ernsthafte Politiker ihre Probleme haben gewählt zu werden, so haben in der Wirtschaft ernsthafte Kaufleute das Problem richtig gewürdigt zu werden, also leistungsmässig richtig eingeschätzt zu werden.

Zudem gibt es noch Formen die lehnen Consulting aus prinzipiellen Gründen ab.
;)

[Cybaer]

Hi,

Jeder gute Verkäufer sollte dem Kunden empfehlen das zu kaufen, was zu verkaufen ist.

Jeder gute Verkäufer, sollte einen Kunden auch zu einem Mitbewerber (ggf. auch kostenfreies Angebot à la Open Source) schicken können, wenn er dem Kunden nicht wirklich mit seinen Produkten helfen kann.

Offensichtlich gibt es da, wie in vielen Bereichen, gravierende Unterschiede in der Bewertung des Wörtchens "gut" - insbesondere wohl, was den vermeintlichen Nutznießer angeht.

Als relativ (und absolut) erfolgreicher ehemaliger Verkäufer (der zudem noch aus einer Kaufmannsfamilie stammt), kann ich dir versichern, daß sich ein "guter Verkäufer" in meinem Sinne durchaus gegen einen "guten Verkäufer" in deinem Sinne durchzusetzen vermag (ich konnte es jedenfalls *immer*).

Aber manche werden das halt nie begreifen, und sind wohl auch nicht gut genug als Verkäufer, als daß sie begreifen würden, daß der kurzfristige Vorteil (des Verkaufens von irgendwas, Hauptsache verkauft) den langfristigen Nachteil (Kunde fühlt sich schlecht beraten und kauft prinzipiell woanders) nicht sticht.

So wie in der Demokratie ernsthafte Politiker ihre Probleme haben gewählt zu werden, so haben in der Wirtschaft ernsthafte Kaufleute das Problem richtig gewürdigt zu werden, also leistungsmässig richtig eingeschätzt zu werden.

Das sehe ich zwar auch so, aber ich hatte das Problem nie. Meine Kunden waren immer zufrieden, und mein Umsatz wuchs entsprechend.

Gruß, Cybaer

[Hamstar]

Als relativ (und absolut) erfolgreicher ehemaliger Verkäufer (der zudem noch aus einer Kaufmannsfamilie stammt), kann ich dir versichern, daß sich ein "guter Verkäufer" in meinem Sinne durchaus gegen einen "guten Verkäufer" in deinem Sinne durchzusetzen vermag (ich konnte es jedenfalls *immer*).

Nö, absolut falsch. Ein in Deinem Sinne guter Verkäufer lehnt sich zu weit aus dem Fenster, erzeugt Misstrauen, stellt sich so zu sagen indirekt selbst in Frage.

Einigen wir uns darauf, dass es kompetente Verkäufer gibt, die "nebenbei" auch noch in der Produktion sitzen und Beratungsqualitäten haben.

Ist dann aber keinesfalls mehr reiner Verkauf. (Was dann wohl auch den Grund für Deine Erfolge darstellt, als Verkäufer bist Du eher ne Flasche. (Was ja auch ganz gut ist.))

[Jörg Lorenz]

Hi Ludger,

Nö, absolut falsch. Ein in Deinem Sinne guter Verkäufer lehnt sich zu weit aus dem Fenster, erzeugt Misstrauen, stellt sich so zu sagen indirekt selbst in Frage.

Einigen wir uns darauf, dass es kompetente Verkäufer gibt, die "nebenbei" auch noch in der Produktion sitzen und Beratungsqualitäten haben.

Ist dann aber keinesfalls mehr reiner Verkauf. (Was dann wohl auch den Grund für Deine Erfolge darstellt, als Verkäufer bist Du eher ne Flasche. (Was ja auch ganz gut ist.))

[ ] Du bist arbeitslos.
[ ] Du bist in einer vermeintlich sicheren Festeinstellung.

Welche der beiden Optionen ist die richtige?

Viele Grüße

Jörg

[Cybaer]

Hi,

Nö, absolut falsch. Ein in Deinem Sinne guter Verkäufer lehnt sich zu weit aus dem Fenster, erzeugt Misstrauen, stellt sich so zu sagen indirekt selbst in Frage.

Wenn Du das sagst.

Ist dann aber keinesfalls mehr reiner Verkauf. (Was dann wohl auch den Grund für Deine Erfolge darstellt, als Verkäufer bist Du eher ne Flasche. (Was ja auch ganz gut ist.))

Oh, ich glaube kaum, daß es seinerzeit viele EDV-Buchhändler gab, die mit EDV-Literatur & Software 7-stellige Jahresumsätze gemacht haben (mit Umsatzsteigerungen von bis zu 100% pro Jahr). Da kann ich ja nur von Glück sagen, daß meine Chefs eine etwas andere Meinung von mir hatten, als Du es in deiner Theorie erschließt und bewertest ... =:->

... ich würde jedenfalls eher sagen, sie haben es in erster Linie sehr gerne gesehen, daß ich schlicht viel verkauft habe - mag man diese Tätigkeit nun auch bezeichnen, wie immer man mag. ;->

Gruß, Cybaer

PS: Daß im Buchhandel eher Mitarbeiter zu finden sind, die ihren Beruf mehr als Berufung verstehen, als z.B. im Media Markt, versteht sich natürlich i.d.R. wohl von selbst. Aber generell sind die, die Chance haben, glücklich in ihrem Beruf zu sein, per se die motivierteren Mitarbeiter sein (auch was z.B. den im beruflichen Umfeld nutzbaren Wissenserwerb in der Freizeit angeht).

[Hamstar]

Nö, absolut falsch. Ein in Deinem Sinne guter Verkäufer lehnt sich zu weit aus dem Fenster, erzeugt Misstrauen, stellt sich so zu sagen indirekt selbst in Frage.

Wenn Du das sagst.

Unsere Verkäufer dagegen sind locker und flockig, echte Milchschwimmer so zu sagen.

Ist dann aber keinesfalls mehr reiner Verkauf. (Was dann wohl auch den Grund für Deine Erfolge darstellt, als Verkäufer bist Du eher ne Flasche. (Was ja auch ganz gut ist.))

Oh, ich glaube kaum, daß es seinerzeit viele EDV-Buchhändler gab, die mit EDV-Literatur & Software 7-stellige Jahresumsätze gemacht haben (mit Umsatzsteigerungen von bis zu 100% pro Jahr). Da kann ich ja nur von Glück sagen, daß meine Chefs eine etwas andere Meinung von mir hatten, als Du es in deiner Theorie erschließt und bewertest ... =:->

Wieso, Du bist für einen Verkäufer eine Spur zu schlau. Das erzeugt Misstrauen. Deine phänomenalen fachlichen Fähigkeiten habe ich doch nicht in Frage gestellt. Auch wenns etwas mit dem Überbau zu hapern scheint. Aber sowas kann man ja mit Fleiss wegbohnern.

... ich würde jedenfalls eher sagen, sie haben es in erster Linie sehr gerne gesehen, daß ich schlicht viel verkauft habe - mag man diese Tätigkeit nun auch bezeichnen, wie immer man mag. ;->

Hast Du früher ausschliesslich verkauft? Wenn ja, was?

PS: Daß im Buchhandel eher Mitarbeiter zu finden sind, die ihren Beruf mehr als Berufung verstehen, als z.B. im Media Markt, versteht sich natürlich i.d.R. wohl von selbst. Aber generell sind die, die Chance haben, glücklich in ihrem Beruf zu sein, per se die motivierteren Mitarbeiter sein (auch was z.B. den im beruflichen Umfeld nutzbaren Wissenserwerb in der Freizeit angeht).

Selbstverständlich. Ich hatte bisher auch immer das ausserordentliche Vergnügen das zu machen, was mir Spass gemacht hat.
Wir sind halt Gewinner.   ;)

[Cybaer]

Hi,

Wieso, Du bist für einen Verkäufer eine Spur zu schlau.

Kann man aber gut gebrauchen, wenn man befördert, und dann Chef wird! ;-)

Das erzeugt Misstrauen.

Also wirklich. Ich weiß nicht, was Du verkaufst, daß Verkäufer mit Wissen "Misstrauen" auslösen sollen. Ist der Verkauf in Deutschland schon so tief gesunken?

Und, äh, es ist zumindest im Buchhandel auch nicht gerade üblich, Kolleginnen (und vereinzelt auch Kollegen ;)) zu haben, die den Eindruck erwecken, sie würden den Job nur machen, weil sie den Hauptschulabschluß nicht gepackt haben und irgendwas geistig anspruchloseres nicht zu finden war. >;->

Hast Du früher ausschliesslich verkauft?

Prinzipiell: Ja. Aber mit beruflich wie privatem Hang zur EDV, war auch im Umfeld immer genug anderes zu tun (Warenwirtschaftssystem, Mitarbeiterschulungen, ...).

Wenn ja, was?

EDV-Bücher, -Software, ein wenig Zubehör und später auch Videospiele.

Ich hatte bisher auch immer das ausserordentliche Vergnügen das zu machen, was mir Spass gemacht hat.

Das ist immer schön zu hören. :)

Gruß, Cybaer

[Hamstar]

Wieso, Du bist für einen Verkäufer eine Spur zu schlau.

Kann man aber gut gebrauchen, wenn man befördert, und dann Chef wird! ;-)

Du und Verkäufer - LOL.

Dass Du vertriebsnah arbeitest nehme ich Dir ab. Ist aber was anderes.

Das erzeugt Misstrauen.
Also wirklich. Ich weiß nicht, was Du verkaufst, daß Verkäufer mit Wissen "Misstrauen" auslösen sollen. Ist der Verkauf in Deutschland schon so tief gesunken?

Du erzeugst Misstrauen. Eitelkeit und so...

[Thomas Schenkeli]

Da ich mit Deinen Codes nicht arbeiten muss, hindere ich Dich nicht daran ;-) Trotzdem solltest Du vielleicht überlegen, ob Du nicht entgegen Deiner persönlichen Präferenz lieber das empfehlen solltest, was eher der allgemeinen Empfehlung entspricht.

Da scheint es im Forum aber auch unterschiedliche Meinungen zu geben (Was jetzt am weitesten verbreitet ist), daher lässt sich das wohl nicht so sagen. Denk mal das wichtigste wird sein für ein Projekt als Ganzes klare Regeln zu entwerfen und sich an diese zu halten.

Cheatah

lg Thomas

[Genie]

Hi

Bei dieser Schreibweise ...

Funktion()
{
    //some Code
}

... kann ich nicht mehr auf einen Blick erkennen, wo die Blöcke anfangen bzw. wozu sie gehören.

Ach. Sie fangen da an, wo die Zeile mit einer öffnenden Klammer beginnt. *Ich* finde das intuitiv.

Ich auch

Zudem wird der Code unübersichtlich lang.

Das riskiere ich

Deswegen schreibe ich die erste Anweisung des Blocks auch gleich in dieselbe Zeile wie die öffnende Klammer:

if (expression)
   { statement;
     statement;
   }

Das aber nicht. Ich schreibe immer so:

  
 if(expression)  
 {  
  statement;  
 }  
 else  
 {  
  statement;  
 }  

Vielleicht etwas länger, aber für mich übersichtlicher

mfg
Genie

[Maxx]

Hallo Martin,

Sowas in der Art wird vermutlich der Grund sein. Weiß der Geier, was dieser Prophet vorher geraucht hat.

nein, geraucht wurde nicht. Zumindest nichts illegales.
Die Schreibweise:
if(...) {
stammt noch aus einer Zeit als die Auswahl an Editoren nicht allzu groß war. Wie auch immer einer der verbreiteteren hat, wenn der Cursor auf einer } stand, die Zeile mit der zugehörigen { angezeigt. Da es heutzutage wesentlich ausgefeiltere und komfortablere Editioren gibt macht das kaum noch jemand.

Grüße,

Jochen

[Bio]

Sup!

Die Diskussion ist ja sooo alt:

http://en.wikipedia.org/wiki/Indent_style

Natürlich ist der "einzig wahre" Stil, der Kernighan-Richie-Stil, der einzig richtige, direkt gefolgt vom BSD-Stil.

Gruesse,

Bio

[Hamstar]

Die Diskussion ist ja sooo alt:

http://en.wikipedia.org/wiki/Indent_style

Natürlich ist der "einzig wahre" Stil, der Kernighan-Richie-Stil, der einzig richtige, direkt gefolgt vom BSD-Stil.

So ein Scheiss ist schwer zu lesen:
if (x < 0) {
    printf("Negative");
    negative(x);
} else {
    printf("Positive");
    positive(x);
}

Wenig ergonomisch...

[Bio]

Sup!

So ein Scheiss ist schwer zu lesen:
if (x < 0) {
    printf("Negative");
    negative(x);
} else {
    printf("Positive");
    positive(x);
}

Ja, da gehen die Meinungen auseinander...; bei uns in der Firma haben wir IMHO den BSD-Stil:

if (x < 0)
{
   printf("Negative");
}
else
{
   printf("Positive");
}

Im Endeffekt ist es aber ziemlich egal, wie man was schreibt; "indent" bekommt es notfalls immer wieder hin.

Gruesse,

Bio

[Hamstar]

Ja, da gehen die Meinungen auseinander...; bei uns in der Firma haben wir IMHO den BSD-Stil:

Ich dachte Du bist Privatier?   ;)

Moment, Firma = FDP?

if (x < 0)
{
   printf("Negative");
}
else
{
   printf("Positive");
}

Im Endeffekt ist es aber ziemlich egal, wie man was schreibt; "indent" bekommt es notfalls immer wieder hin.

Es läuft auf die Frage hinaus, ob die Blockbegrenzer (hier die geschweiften Klammern, das kann aber auch ein BEGIN (hat nichts mit dem früheren israel. Ministerpräsidenten gleichen namens zu tun) und ein END sein, zur selben logischen Ebene gehören wie der bedingt auszuführende Block.

Wie sieht denn bspw. folgendes ("Transact-SQL", MS) aus?

IF (x < 0)
BEGIN
  printf("Negative");
END
ELSE
BEGIN
  printf("Positive");
END

Würgg, oder?

IF (x < 0)
  BEGIN
  printf("Negative");
  END
ELSE
  BEGIN
  printf("Positive");
  END

So ist es gleich schon besser, oder?

Noch schöner:
IF (x < 0)
  BEGIN
  --
  printf("Negative");
  --
  END
ELSE
  BEGIN
  --
  printf("Positive");
  --
  END

So ist es doch gleich schon viel besser, oder? (Das 'oder' bitte jeweils als Frage rhetorischer Natur interpretieren.)

Warum die '--' (Kommentarbeginnzeichen in T-SQL)?
Antwort: Damit sich die Codeblöcke (bzw. die Entwickleraugen) nicht an den Blockbegrenzern weh tun.

[Bio]

Sup!

Ich dachte Du bist Privatier?   ;)

Schön wär's.

Moment, Firma = FDP?

Ne. Voll nicht. ;-)

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

Darum mag ich im Prinzip so eine if-elseif*-else-endif-Syntax.

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

ist doch supi. Wer braucht da Klammern.

Gruesse,

Bio

[Hamstar]

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

[Hamstar]

Funktion() {
    //some Code
}

Warum nicht:

Funktion()
{
    //some Code
}

???
Ich empfinde Zweiteres als um vieles leichter lesbar.

Wesentlich logischer ist:
Funktion()
  {
  //some Code
  }

[Hamstar]

Wesentlich logischer ist:
Funktion()
  {
  //some Code
  }

Oder:
Funktion f
  (
  param1,
  param2
  )
  {
  //some Code
  }

[Thomas Schenkeli]

Wesentlich logischer ist: Funktion()   {   //some Code   }

Oder: Funktion f   (   param1,   param2   )   {   //some Code   }

Also da dürfte es eventuell zu Problemen kommen da laut JavaScript-Spezifikation zwischen dem Funktionsnamen und der "("-Klamer kein Leerzeichen sein darf, also wohl auch kein Zeilenumbruch mit Tabulator (abgesehen davon, dass zum Einrücken sowieso Leerzeichen zu verwenden sind)

lg Thomas

[Mathias Brodala]

Hallo Thomas.

Funktion f
  (
  param1,
  param2
  )
  {
  //some Code
  }

Also da dürfte es eventuell zu Problemen kommen da laut JavaScript-Spezifikation zwischen dem Funktionsnamen und der "("-Klamer kein Leerzeichen sein darf, also wohl auch kein Zeilenumbruch mit Tabulator (abgesehen davon, dass zum Einrücken sowieso Leerzeichen zu verwenden sind)

Wo hast du dies denn her? Ich kann hier nichts davon lesen und bin auch bisher nie auf Probleme mit Whitespaces gestoßen.

Einen schönen Freitag noch.

Gruß, Mathias

[Tim Tepaße]

Hallo Mathias, Thomas,

Also da dürfte es eventuell zu Problemen kommen da laut JavaScript-Spezifikation zwischen dem Funktionsnamen und der "("-Klamer kein Leerzeichen sein darf [...]
Wo hast du dies denn her? Ich kann hier nichts davon lesen [...]

Auch in der offiziellen Spezifikation ECMAScript steht nichts davon:

Clause 13 Function Definition:

FunctionDeclaration :
      function Identifier ( FormalParameterListopt ){ FunctionBody }

Clause 7.2 White Space:

„White space characters are used to improve source text readability and to
  separate tokens (indivisible lexical units) from each other, but are otherwise
  insignificant. White space may occur between any two tokens [...]“

Token sind nach 7.4 die Nonterminale ReservedWord, Identifier, Punctuator, NumericLiteral und StringLiteral. In obiger FunctionDeclaration ist „function“ ein ReservedWord, „Identifier“ ist – Überraschung! – ein Identifier und die Zeichen „(“, „)“, „{“, und „}“ sind Puncuators. Alles Token, zwischen Token ist Whitespace erlaubt.

Auch in der offiziellen PDF-Version von ECMAScript ist das so definiert.

Tim

[Thomas Schenkeli]

Wo hast du dies denn her? Ich kann hier nichts davon lesen und bin auch bisher nie auf Probleme mit Whitespaces gestoßen.

Mein Fehler: gilt nur für anonyme Funktionen:

"If a function literal is anonymous, there should be one space between the word function and the ( (left parenthesis). If the space is omited, then it can appear that the function's name is function, which is incorrect."

http://www.crockford.com/

Einen schönen Freitag noch.

Gruß, Mathias

lg thomas

[Tim Tepaße]

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

[Hamstar]

Funktion f
  (
  param1,
  param2
  )
  {
  //some Code
  }

Also da dürfte es eventuell zu Problemen kommen da laut JavaScript-Spezifikation zwischen dem Funktionsnamen und der "("-Klamer kein Leerzeichen sein darf, also wohl auch kein Zeilenumbruch mit Tabulator (abgesehen davon, dass zum Einrücken sowieso Leerzeichen zu verwenden sind)

Ich habe es eher abstrakt gemeint (ehrlich gesagt entging mir der JS-Kontext völlig), ich weiss nicht, ob manche Browser bei der o.g. Schreibweise zicken.

Recht beliebt ürbrigens auch:

Funktion f(param1,param2){//some Code}

Das sieht auch ganz gut aus, aber wenn die Parameter mehr werden und der "some Code" auch, dann gute Nacht.

[Tim Tepaße]

Hallo,

um mal den typischen Troll zu mimen: Der einzig wahre Stil ist doch das Verzichten auf Klammern um Blöcke:

def func(args):  
    tuedies()  
    tuedas()

;)

(Ansonsten natürlich K&R)

Tim

[Hamstar]

um mal den typischen Troll zu mimen: Der einzig wahre Stil ist doch das Verzichten auf Klammern um Blöcke:

def func(args):

tuedies()
    tuedas()

>   
> ;)  
  
Ist mir auf den ersten Blick gar nicht so unsympatisch, wobei ich geschweifte und runde Klammern allerdings durchaus mag (weniger eckige ;).  
  
Was macht den o.g. Vorschlag trollig? Oder ist die Diskussion bereits trollig? (Weil "der Profi" ja "sowieso" alles in seinen Editor lädt und der Editor die Formatierung besorgt?)

[Tim Tepaße]

Hallo Ludger,

Was macht den o.g. Vorschlag trollig?

Ich mimte nur den Troll, der in einer Diskussion blind seine bevorzugte Programmiersprache empfiehlt. Was ich da ja auch gemacht habe, Python ist derzeit meine bevorzugte Sprache.

Oder ist die Diskussion bereits trollig? (Weil "der Profi" ja "sowieso" alles in seinen Editor lädt und der Editor die Formatierung besorgt?)

Würde ich nicht sagen, bei Freiformsprache braucht es nun mal Style Guides wegen der Zusammenarbeit. Es wäre ja sehr störend, spränge des Diff des Versionsverwaltungsprogramm an, nur weil sich der Stil geändert hat, nicht aber die Substanz. Natürlich kann man zur Bearbeitung in seiner Arbeitskopie alles umformatieren und vor dem Einchecken in das Versionverwaltungsprogramm wieder alles in den Style Guide ändern. Aber ein Roundtrip durch das Umformatierprogramm sollte dann nichts verändern; das ist dann eine ziemlich große Quelle potentieller Nerverei.

(Und ja, es gibt Ideen, das zu entkoppeln, z.B. die abstrakte Syntax in der Form von XML zu definieren und einen Diff auf der Ebene des DOMs zu machen. Aber hey - XML für Programme?)

Tim

[Hamstar]

Was macht den o.g. Vorschlag trollig?

Ich mimte nur den Troll, der in einer Diskussion blind seine bevorzugte Programmiersprache empfiehlt.

Dann bin ich ja beruhigt.

XML für Programme?

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

Ich habe noch mal ein wenig über white space, Anweisungsbegrenzer und Anweisungsblockbegrenzer nachgedacht.

Also, soweit wie in BASIC darf es nicht kommen, dass der Zeilenvorschub/Wagenrücklauf, also "white space", die Programmlogik beeinflusst. (Ich erinnere nur an das schreckliche \_ zum Verlängern von Programmzeilen.)

Eine Funktion sollte zudem seine Anweisungen mit Anweisungsblockbegrenzern umschranken.

Bzgl. der Notation habe ich mich ja schon (etwas polemisch natürlich um die Sache auf den Punkt zu bringen, armer Skeeve (der "Skeeve is in da house"-Skeeve ;)!) geäussert.

Von der "Christoph Zurnieden"-Argumentation ("Ich schmeisse eh alles in meinen Editor.") halte ich, genau wie Du, auch nicht viel.

[Tim Tepaße]

Hallo Ludger,

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?

Eine Funktion sollte zudem seine Anweisungen mit Anweisungsblockbegrenzern umschranken.

Warum das?

Tim

[Hamstar]

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.

[Hamstar]

In diese Thematik spielt auch der Anweisungsbegrenzer hinein (bspw. das nette ";" in COBOL, PHP und Perl).

LOL - es ist natürlich ein '.' in COBOL.

[Tim Tepaße]

Hallo Ludger,

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

Jepp, aber dies geschieht ja nicht notwendigerweise durch ein "end" bzw. ein "}".

Klar, manche könnten jetzt meinen, dass der Zeilenvorschub/Wagenrücklauf ja die Eindeutigkeit besorgen könnte

Nicht nur der Zeilenvorschub sondern auch die Einrückung.

Genau das ist meine Argumentation. Seit mindestens zwei Jahrzehnten hat sich auch in allen von Algol abstammenden Freiformsprachen der Stil rausgebildet, begrenzte Blöcke je eine Stufe einzurücken und meistens jede Anweisung/Ausdruck auf eine Zeile zu setzen. So ziemlich jeder Programmierer macht das in 95 % der Fälle; es ist sozusagen also ein kulturelles Erbe. Python kodifiziert nun diesen Stil und nutzt diesen zum Erkennen der Eindeutigkeit eines Blocks, ohne das sonstige Begrenzer (ausser den Keywords) notwendig sind.

(meinen Kommentar dazu kennst Du).

Nicht wirklich. Ich hab BASIC immer links liegen lassen (andere Generation), insofern kann ich Deine Andeutungen nicht nachvollziehen.

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).

Nein, ist sie nicht. Bei Python wird das Ende der Funktion dadurch festgestellt, dass der Inhalt der nächsten Zeile eine Stufe weniger eingerückt ist, als der Inhalt der Funktion/des Konditionals/der Schleife/der Klasse. Durch Einrückung kann man ja wunderbar einen Baum aufbauen.

Tim

[Hamstar]

Nein, ist sie nicht. Bei Python wird das Ende der Funktion dadurch festgestellt, dass der Inhalt der nächsten Zeile eine Stufe weniger eingerückt ist, als der Inhalt der Funktion/des Konditionals/der Schleife/der Klasse. Durch Einrückung kann man ja wunderbar einen Baum aufbauen.

Es lebe der white space!
Dummerweise gibts dann beim Kopieren und Verstehen für den Menschen Probleme.
Aber interessant, dass man bei so elementaren Fragen anderer Meinung sein kann (ich meine jetzt eher die Python-Leute).

Man könnte das auch weiterdenken, also Parametriesierung von Funktionen per Einrückung und - ja! - man könnte versuchen bspw. das "IF" zu ersetzen (6 spaces-Einrückung?) und auch die gute alte Schleife könnte in der Python-Welt eine wunderbare Überarbeitung erfahren.

[Tim Tepaße]

Hallo Ludger,

Dummerweise gibts dann beim Kopieren und Verstehen für den Menschen Probleme.

Nö, in der Praxis eigentlich nicht.

Man könnte das auch weiterdenken, also Parametriesierung von Funktionen per Einrückung und - ja! - man könnte versuchen bspw. das "IF" zu ersetzen (6 spaces-Einrückung?)

Das halte ich wiederrum für Unfug. Ausserdem müssen Funktionssignaturen und Konditionen dennoch irgendwo hin, deswegen sind Statements ganz toll.

und auch die gute alte Schleife könnte in der Python-Welt eine wunderbare Überarbeitung erfahren.

Hat sie schon. Das klassische for (i; i < irgendwas; i++) { ... } gibt's in Python nicht, dort wird nur über Kollektionen oder Iteratoren iteriert.

Tim

[Skeeve]

Moin!

Ich empfinde Zweiteres als um vieles leichter lesbar. Gibt es einen speziellen Grund warum sich aber Ersteres durchgesetzt hat oder einfach nur weil vor tausenden von Jahren ein Prophet sich dazu entschlossen hat diese Version zu födern?

Das ist ja schön im wikipedia Artikel erklärt.

Da ich vor Äonen das Programmieren lernte (MCMLXXX um genau zu sein), habe ich mich natürlich auch daran gewöhnt und finde es um *LÄNGEN* besser zu lesen als sämtliche anderen, dort vorgestellten Varianten. Das else schreibe ich aber nicht wie dort beschrieben, sondern so:

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

Allerdings: "Wes' Brot ich ess, des' Lied ich sing". Wenn es also projektbezogene Formatierrichtlinien gibt, dann sehe ich zu, diese auch einzuhalten, im Zweifel durch Verwendung eines prettyprinters.

-- Skeeve

[Hamstar]

if ( $x < 0 ) {

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

  
Aber Dir ist schon klar, dass die geschweiften Klammern so eher eine Belästing, denn eine Hilfe sind?

[Skeeve]

Moin!

Aber Dir ist schon klar, dass die geschweiften Klammern so eher eine Belästing, denn eine Hilfe sind?

Mich haben die seit 26 Jahren nicht belästigt.

Also Nein! Wie kommst Du darauf?

Wen belästigen sie?

Dich?

Dir ist schon klar, daß ich nicht für Dich programmiere, oder? ;-)

Andererseits... Wenn Du mich bezahlst (s.o.) und mir sagst, daß ich das anders machen soll: Herzlich willkommen!

-- Skeeve

[Hamstar]

Aber Dir ist schon klar, dass die geschweiften Klammern so eher eine Belästing, denn eine Hilfe sind?
Mich haben die seit 26 Jahren nicht belästigt.

Gut, dann muss ich das noch mal schön langsam erklären:

1.Fall: geschweifte Klammern mit störender Wirkung:

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

2.Fall: ohne Klammern

if ( $x < 0 )  
    print "negative";  
elsif ( $x > 0 )  
    print "positive";  
else  
    print "zero";  
end if  

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

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

Für mich ist Variante 1 ganz klar die übelste (und populärste). Unübersichtlich, Syntaxfehler sind schwerer zu finden und Kopieren von Code wird schwieriger. Der zur Verfügung stehende Platz wird vertikal suboptimal ausgenutzt.

Man kann natürlich auch anderer Meinung sein, mir geht es ausschliesslich darum meine Meinung verständlich zu machen.

[Skeeve]

Moin!

Gut, dann muss ich das noch mal schön langsam erklären:

Okay... Ich auch... Beispiele kopiere ich nicht mit. Ich beziehe mich auf Deine.

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. 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.

Kopieren von Code wird schwieriger.

Das mußt Du mir mal erklären.

Man kann natürlich auch anderer Meinung sein, mir geht es ausschliesslich darum meine Meinung verständlich zu machen.

Dito.

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

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".

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.

-- Skeeve

[Hamstar]

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.

[Skeeve]

Moin!

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

Eben!

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

Ja. Macht doch nix.

Kopieren von Code wird schwieriger.
Das mußt Du mir mal erklären.
Man kann die Blöcke nicht so gut "anfassen".

Hatte ich bisher keine Probleme mit.

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.

Ich programmiere schon ewig kein Pascal mehr. Aber wie dem auch sei: Ich habe nicht gesagt, daß ich genau diese Formatierung stur in jeder Sprache durchziehe.

D.h. Variante 1 geht nur mit manchen Programmiersprachen, Variante 3 (mit sauber horizontal und vertikal abgesetzten Blockbegrenzern) immer.

So what? Ich darf mich zwar auf Altersstarrsinn berufen, aber so flexibel bin ich denn doch, daß ich "adaptiv formatiere". ;-)

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.

Nope. Meins ist Perl.

Mag sein, aber "Variante 3" ist die Einfachste, d.h. sie kommt mit den wenigsten Regeln aus.

! Einfach => Besser ;-)

Zudem hat sie mir schon wertvolle Dienste bei der Codebesichtigung geleistet, was ich von "Variante 1" (und fremden Code) nun wirklich nicht sagen kann.

That's what pretty printers are for. In meinem Fall darfst Du dann perltidy gerne mit der passenden Option aufrufen um Deine Lieblingsformatierung zu erhalten.

Wichtig ist mir, dass meine Argumente verstanden werden.

Was sind das für Argumente "Mir hat die Formatierung geholfen"? Mir hilft meine. Es steht also unentschieden.

-- Skeeve

[Hamstar]

Wichtig ist mir, dass meine Argumente verstanden werden.
Was sind das für Argumente "Mir hat die Formatierung geholfen"? Mir hilft meine. Es steht also unentschieden.

Nun, für Dich also _noch_einmal_ die Hauptargumente für Whitesmiths style vs. "K&R":

• Einfachheit
• Regel funktioniert mit allen Programmiersprachen (im Gegensatz zu "K&R")
• Ergonomie (kein Vermischen von Blockbegrenzern und Bedingungen in einer Zeile, Kopieren von Blöcken aus Cursorposition "x=0" möglich, "Augenfreundlichkeit" (selbst "K&R"-Junkies werden das nach einer Eingewöhnungsphase einräumen) etc.)
• optimale vertikale und horizontale Nutzung von white space

Zusammengefasst sind die Argumente für Whitesmiths style erdrückend. (Ausserdem darf angenommen werden, dass Verfechter von "K&R" grundsätzlich gegen das erste Gebot der IT, die Einfachheit, verstossen und Folgetaten zu erwarten sind. Kein Wunder, dass solche Leute u.a. auch Datendesignfragen mit Performanceüberlegungen mischen und quasi jederzeit mit aus der Hüfte geschossenen Lösungen den Betrieb strapazieren. Wer Einfachheit als Prinzip nicht versteht und angewandte Einfachheit (schon in diesem elementaren Fall!) nicht erkennt, der ist im IT-Brereich potentiell brandgefährlich. - Aber ich will mich nicht weiter aufregen... ;)

[Skeeve]

Moin!

Aber ich will mich nicht weiter aufregen... ;)

Dann schreibe ich nix weiter dazu. War mir eh zu polemisch ("K&R Junkies").

-- Skeeve

[Hamstar]

Aber ich will mich nicht weiter aufregen... ;)
Dann schreibe ich nix weiter dazu. War mir eh zu polemisch ("K&R Junkies").

Erstens hast Du schon etwas dazu geschrieben, zweitens scheinen Dir die Argumente ausgegangen zu sein.

BTW - "Variante 2" hätte ich auch noch gerne in die Manghel genommen.   ;)

[Benjamin Buxbaum]

Hi!

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. 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. Die Blöcke im obigen Beispiel hingegen sehen irgendwie losgelöst aus. Gefällt mir nicht.  
  
mfG

-- 
[sh:( fo:§ ch:{ rl:? br:> n4:# ie:} mo:? va:) de:µ zu:| fl:( ss:{ ls:~ js:)](http://community.de.selfhtml.org/fanprojekte/selfcode.htm)  
  
"And all those exclamation marks, you notice? Five? A sure sign of someone who wears his underpants on his head."  
(Terry Pratchett)

[Hamstar]

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!

[Benjamin Buxbaum]

Hi!

Du kannst Dir vorstellen, dass meine Augen immerhin nur vertikal suchen müssen, da die öffnenden und schliessenden Klammern mit gleichem "X-Wert" kommen?

Du kannst Dir vorstellen, dass meine Augen ebenfalls nur vertikal suchen, da schließende Klammer und zugehöriger Ausdruck mit gleichem "X-Wert" kommen? Ich sehe genau, wo ein Block beginnt und wo er endet. Außerdem spare ich eine überflüssige Zeile ein.

"Irgendwie losgelöst"?!

Die sind optisch optimal abgesetzt!

Was mich daran unter anderem noch stört: Der Code zwischen den Klammern steht auf gleicher Höhe wie die Klammern selbst. Das ist für mich alles andere als optimal abgesetzt.

mfG

[Hamstar]

Du kannst Dir vorstellen, dass meine Augen ebenfalls nur vertikal suchen, da schließende Klammer und zugehöriger Ausdruck mit gleichem "X-Wert" kommen? Ich sehe genau, wo ein Block beginnt und wo er endet. Außerdem spare ich eine überflüssige Zeile ein.

f () {
//somecode}

oder

f () {
//somecode
}

Weiss nicht, ich sehe da andere "X-Werte" für die Geschweiften. Und wenn dann noch irgendwelche Anweisungsblöcke, die wiederum mit den Geschweiften Unfug treiben hinzukommen, dann hat man den Salat.

Was mich daran unter anderem noch stört: Der Code zwischen den Klammern steht auf gleicher Höhe wie die Klammern selbst. Das ist für mich alles andere als optimal abgesetzt.

Dass die Geschweiften beim von mir als optimal vorgestellten Notationsstil auf derselben Höhe stehen bzw. gleichermassen abgesetzt sind wie der Anweisungsblock, liegt ganz einfach daran, dass Anweisungsblockbegrenzer und Anweisungsblock zusammengehören. So ähnlich wie eine Mohrrübe und ihre Schale.

[.nils.]

Hallo,

Das ist ja schön im wikipedia Artikel erklärt.

Was fürn Artikel?

Gruß, Nils

[Struppi]

Funktion() {
    //some Code
}

Warum nicht:

Funktion()
{
    //some Code
}

???
Ich empfinde Zweiteres als um vieles leichter lesbar.

Geht mir genauso, ich empfinde das erste ebenfalls extrem unleserlich.

Struppi.

[Jörg Lorenz]

Moin,

Ich empfinde Zweiteres als um vieles leichter lesbar.

das mit den Klammern ist mir persönlich gar nicht mal so wichtig. Ich ärgere mich dafür öfter über den Einsatz von Variablennamen in längeren Codeteilen. Wie schön wäre es, wenn alle sprechende Variablennamen verwenden würden. Und wie schön wäre es, wenn man an den Variablennamen erkennen würde, welcher Datentyp sich dahinter verbirgt …

Viele Grüße

Jörg

[Der Martin]

Hallo,

Wie schön wäre es, wenn alle sprechende Variablennamen verwenden würden.

oh ja, da stimme ich vorbehaltlos zu.

Und wie schön wäre es, wenn man an den Variablennamen erkennen würde, welcher Datentyp sich dahinter verbirgt …

Das halte ich wieder für wenig sinnvoll. Ich möchte aus dem Variablennamen in erster Linie den *Verwendungszweck* ablesen, eventuell noch das Modul, zu dem die Variable gehört. Der Typ ergibt sich entweder automatisch daraus oder ist für das Verständnis nicht wichtig.
Typbestimmende Präfixe machen mir das Lesen und Verstehen eher schwerer als leichter.

Ciao,
 Martin

[Jörg Lorenz]

Moin moin,

Das halte ich wieder für wenig sinnvoll. Ich möchte aus dem Variablennamen in erster Linie den *Verwendungszweck* ablesen, eventuell noch das Modul, zu dem die Variable gehört. Der Typ ergibt sich entweder automatisch daraus oder ist für das Verständnis nicht wichtig.
Typbestimmende Präfixe machen mir das Lesen und Verstehen eher schwerer als leichter.

naja, ist halt Geschmackssache. Bei intRechnungsNummer weiß ich, dass da nur eine Zahl enthalten sein darf, bei strRechnungsNummer kann die auch mal den Aufbau "A-00055" haben.

Jeder halt nach seinen Vorlieben …

Allerdings schreibe ich auch überwiegend in VB, wo es keine automatische Typumwandlung gibt.

Viele Grüße

Jörg

[Der Martin]

Hi,

Typbestimmende Präfixe machen mir das Lesen und Verstehen eher schwerer als leichter.
naja, ist halt Geschmackssache. Bei intRechnungsNummer weiß ich, dass da nur eine Zahl enthalten sein darf, bei strRechnungsNummer kann die auch mal den Aufbau "A-00055" haben.

ja, schon richtig. Aber ob die Rechnungsnummer nun alphanumerisch oder rein numerisch ist, spielt für das Verständnis und das Nachvollziehen der Programmlogik auch keine Rolle. Es ist eine Information, die nur an der Benutzerschnittstelle auftritt (und irgendwo im Speicherformat der Daten).

Allerdings schreibe ich auch überwiegend in VB, wo es keine automatische Typumwandlung gibt.

Ich befasse mich überwiegend mit C, wo zwar zuweisungskompatible Typen (z.B. int vs. char) automatisch umgewandelt werden, ansonsten die Typentreue recht hoch ist. Daher nervt mich auch gelegentlich die Typenlosigkeit von Javascript oder PHP.

So long,
 Martin

[Jörg Lorenz]

Hi Martin,

naja, ist halt Geschmackssache. Bei intRechnungsNummer weiß ich, dass da nur eine Zahl enthalten sein darf, bei strRechnungsNummer kann die auch mal den Aufbau "A-00055" haben.

ja, schon richtig. Aber ob die Rechnungsnummer nun alphanumerisch oder rein numerisch ist, spielt für das Verständnis und das Nachvollziehen der Programmlogik auch keine Rolle. Es ist eine Information, die nur an der Benutzerschnittstelle auftritt (und irgendwo im Speicherformat der Daten).

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.

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 es heißen würde: strDateiName

Dann wäre klar, dass die Variable als String deklariert wurde und demzufolge kein Boolean sein kann.

Ich befasse mich überwiegend mit C, wo zwar zuweisungskompatible Typen (z.B. int vs. char) automatisch umgewandelt werden, ansonsten die Typentreue recht hoch ist. Daher nervt mich auch gelegentlich die Typenlosigkeit von Javascript oder PHP.

Das ist mir ziemlich schnell aufgefallen, als ich vor ungefähr zwei Jahren begonnen hatte, mich mit PHP zu beschäftigen. Ich finde, man wird dadurch auch nachlässig im Umgang mit Datentypen.

Einen schönen Abend

Jörg

[MudGuard]

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

[Jörg Lorenz]

Moin Andreas,

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.

sicher, aber damit muss man leben.

Alternativen wären,

• die Deklaration wegfallen zu lassen oder
• alles als Variant zu deklarieren, was aber dem vorherigen Punkt entspricht.

Bei kleineren Projekten sollte das kein Problem sein. Bei größeren Geschichten merkt man dann aber schon, wie das Programm immer langsamer läuft.

Viele Grüße

Jörg

[MudGuard]

Hi,

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.
sicher, aber damit muss man leben.
Alternativen wären,

• die Deklaration wegfallen zu lassen oder
• alles als Variant zu deklarieren, was aber dem vorherigen Punkt entspricht.

• eine andere Sprache benutzen, die strenge Typisierung hat

cu,
Andreas

[Skeeve]

Moin!

Wie schön wäre es, wenn alle sprechende Variablennamen verwenden würden.

Ich ärgere mich in vielen Java Programmen darüber, daß die Dateinamen nicht "sprechend" sondern *geschwätzig* sind.

Und wie schön wäre es, wenn man an den Variablennamen erkennen würde, welcher Datentyp sich dahinter verbirgt …

Das, denke ich, ist unnötig. Wenn Du das absolut brauchst, geh zurück zu C64 Basic ;-) Da hieß es noch i% für Integer und s$ für String ;-) Wenn man eine gute Entwicklungsumgebung hat, dann "sagt" die einem den Typ einer jeden Variable.

-- Skeeve

[Jörg Lorenz]

Hi,

Das, denke ich, ist unnötig. Wenn Du das absolut brauchst, geh zurück zu C64 Basic ;-) Da hieß es noch i% für Integer und s$ für String ;-)

naja, mit VB geht das auch heute noch. ;-)

Wenn man eine gute Entwicklungsumgebung hat, dann "sagt" die einem den Typ einer jeden Variable.

Ja, ist sicher Geschmackssache. Mir ist's halt lieber, wenn ich es gleich am Namen sehe.

Viele Grüße

Jörg

[seth]

gudn tach Thomas!

die indent-styles sind geschmackssache, was man ja auch an dieser diskussion wieder gesehen hat.
ich persoenlich habe gerne moeglichst viel code vor mir und scrolle ungern viel. anderen ist es wichtiger, wenn im code viel "platz" ist.

das thema hatten wir uebrigens schon oefters, z.b. </archiv/2004/12/t97096/#m591230>. da wurden dann auch indent und astyle genannt, die einem den code in etwa so formatieren koennen, wie man's gerne haette.
das hat dann den vorteil, dass jeder seinen persoenlichen coding-stil einhalten kann. in der praxis ist die konvertierung der verschiedenen stile jedoch oft nicht 100%-ig moeglich, weshalb sich dann doch oft zu beginn auf einen stil geeinigt wird.

prost
seth

[.nils.]

Hallo,

Ich nutze die erste Schreibweise für Methoden und die zweite für Klassen (bzw in Javascript Für Prototypen-Funktionen). Oder ich nutze die wunderbare Sprache Python, da muß ich mir über so wat keine Gedanken machen :-)

(Falls jemand diese Meinung bereits geäußert haben sollte, Threads, die länger sind als 10 Einträge, lese ich aus Faulheit selten vollständig)

Gruß, Nils

[annA]

Hallo Thomas,

bei Sprachen, die ein function oder class benötigen, mach ich es sogar noch andersers (ich bin hesse, ich darf das ;)

function
blockIP() {

}

:)

Gruß
annA

[Hamstar]

bei Sprachen, die ein function oder class benötigen, mach ich es sogar noch andersers (ich bin hesse, ich darf das ;)

function
blockIP() {

}

Das sieht aber traurig aus, warum nicht:

function f
  (
  //blahh
  )
  {
  //blööh
  }

[seth]

gudn tach!

bei Sprachen, die ein function oder class benötigen, mach ich es sogar noch andersers (ich bin hesse, ich darf das ;)

"annerschder" (wobei "er" fuer aussenstehende kaum von "ä" zu unterscheiden ist).

function
blockIP() {

}

na, jetzt haette ich aber eher sowas erwartet wie

uffgab
wolle_mer_se_railasse() {

}

<traeum> ach du scheisse, stellt euch mal vor alle computersprachen waeren hessisch! hmmm, cool! </traeum>

prost
seth

[Struppi]

wolle_mer_se_railasse() {

du verwechselst hier die Rheinseiten, dieser Spruch entspringt dem Mainzer Karneval, wovon der Hesse nur relativ wenig versteht.
(Wobei für mich als Zugezogener, die Dialekte tatsächlich ähneln)

Struppi.

[seth_not@home]

gudn tach!

wolle_mer_se_railasse() {

du verwechselst hier die Rheinseiten

nee, nee. dialekte sind ja nicht disjunkt.

dieser Spruch entspringt dem Mainzer Karneval, wovon der Hesse nur relativ wenig versteht.

vom mainzer karneval haben die hessen tatsaechlich weniger ahnung (als z.b. die mainzer). aber die hessen feiern ja auch fassenacht. und zumindest in mittel- bis suedhessen ist dieser spruch ebenfalls im gebrauch.
und die frankfurter fassenacht ist auch nicht ohne. da wird halt bloss mehr aebbler getrunken.

prost
seth

[hkl]

Hallo Ihr Jecken !

Was soll diese Diskussion - das kann man doch viel kurzer in Code ausdruecken

  
return ( pHesse->afa_zu_babbele() && ( ! pHesse->uffhoere() ) );  
/*  
 * pHesse->uffhoere() sollte stets in einem eigenen Thread ausgefuehrt werden denn "wenn die Hesse ersmal afa zu babbele denn hern se so schnell nit widder uff"  
 */  
  
// un jut is...  

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" !
( Das ist wie .NET nur macht der Absturz mehr Spass )

Taeraeaeae !

Holger

[seth_not@home]

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

[hkl]

Wo sagt man das in hessen?

Meinte das im hessischen Teil der Rhoen vernommen zu haben.
Waehrend der stengen Grenzabfertigung als ich von Franken kommend dorthin wollte...
:-)

Zum Frankfuerter Dialekt kann ich nichts sagen - tagsueber war's hochdeutsch und abends gab's Aebbelwoi ( schreib ich das richtig ? )

'Aebbelwoi' ist doch hessisch fuer

[code lang=sh]
cat /dev/zero > /dev/brain && aspirin_me(next_day)
[code]

oder nicht ?

Drink mer noch a Troebbsche...

Holger

[seth]

gudn tach!

Aebbelwoi ( schreib ich das richtig ? )

ja, afais eine der richtigen schreibweisen. (andere wuerden jedoch "ae" als umlaut schreiben).
aber das ist nicht einheitlich: siehe http://de.wikipedia.org/wiki/Apfelwein oder auch http://www.possmann.de/mundart/gebabbel.htm (flash-plugin benoetigt)

prost
seth

[Struppi]

wolle_mer_se_railasse() {

du verwechselst hier die Rheinseiten

nee, nee. dialekte sind ja nicht disjunkt.

dieser Spruch entspringt dem Mainzer Karneval, wovon der Hesse nur relativ wenig versteht.

vom mainzer karneval haben die hessen tatsaechlich weniger ahnung (als z.b. die mainzer). aber die hessen feiern ja auch fassenacht. und zumindest in mittel- bis suedhessen ist dieser spruch ebenfalls im gebrauch.

Ein Fehler meinerseits, der vermutlich an der frühen Morgenstunde lag, es heißt hier ja auch: wolle_mor_se_roilosse()

Jetzt sing ich erstmal das Schweinekotzelied.

Struppi.

[Der Martin]

Hallo,

<traeum> ach du scheisse, stellt euch mal vor alle computersprachen waeren hessisch! hmmm, cool! </traeum>

*den* Alptraum hatte ich zum Glück noch nicht. Puh, das wäre ja grausam!

Ciao,
 Martin