Moin,

ich habe viele lange zeilen in meinem code und Frage mich daher, wies es richtig - ich weiss das es da (eigentlich) keine regeln gibt - auszusehen hat.

Wie würden die Borlander wohl diese Zeile schreiben?

Query := PChar(Format('INSERT INTO %s(nickname, password, email, newsletter, shareinfo) ', [TABLE_USERS]) + Format('VALUES(%0:s%1:s%0:s,%0:s%2:s%0:s,%0:s%3:s%0:s,%0:s%4:d%0:s,%0:s%5:d%0:s);', [#39, Nick, iif(MD5Pass, MD5DigestToStr(MD5String(_enc(Pass))), _enc(Pass)), Mail, Newsletter, ShareInfo])); Nicht über das doppelte Format wundern, ich hatte die Zeile bei mir nur aufgeteilt...

Wie würde die Funktion und vorallem wo geteilt werden? Für einen Einzeiler wäre das ja ein bisschen lang. Und wenn aufgeteilt wird, wieviele Zeilen rückt man ein?

Nach dem DelphiTreff-StyleGuide:

Zitat:

Eine einfache Anweisung enthält einen einzelnen Strichpunkt. Wenn es nötig ist, die Anweisung auf mehrere Zeilen zu verteilen, rücken Sie die zweite Zeile zwei Leerstellen mehr ein als die vorherige Zeile.

Wobei 1 Tab natürlich besser wäre.
Den Zeilenumbruch würde ich an einer möglichst niedrigen "Klammern-Ebene" machen:

markieren

Delphi-Quellcode:

Query := PChar(Format('INSERT INTO %s(nickname, password, email, newsletter, shareinfo) ',
  [TABLE_USERS]) + Format('VALUES(%0:s%1:s%0:s,%0:s%2:s%0:s,%0:s%3:s%0:s,%0:s%4:d%0:s,%0:s%5:d%0:s);',
  [#39, Nick, iif(MD5Pass, MD5DigestToStr(MD5String(_enc(Pass))), _enc(Pass)), Mail, Newsletter, ShareInfo]));

danke dir genauso haette ich es auch gemacht, ich wusste halt nur nicht ob es richtig ist

Die erlaubte Zeilenlaenge muss man selber festlegen. Bei der JVCL haben wir uns auf 120 Zeichen geeinigt.

markieren

Delphi-Quellcode:

Query := PChar(Format('INSERT INTO %s(nickname, password, email, newsletter, shareinfo) ', [TABLE_USERS]) +
  Format('VALUES(%0:s%1:s%0:s,%0:s%2:s%0:s,%0:s%3:s%0:s,%0:s%4:d%0:s,%0:s%5:d%0:s);',
    [#39, Nick, iif(MD5Pass, MD5DigestToStr(MD5String(_enc(Pass))), _enc(Pass)), Mail, Newsletter, ShareInfo]));

Die Einrueckung ist ueblicherweise 2 Leerzeichen. Tabulatoren sollte man vermeiden.
Beim obengenannten Statement wuerde ich wie gezeigt umbrechen.
Die Idee dabei ist wenn moeglich die durch Komma getrennten Einheiten nicht auseinanderzureissen. das gleiche gilt fuer die eckigen Klammern.
So bleibt es am leichtesten zu verstehen.

Da war jemand schneller
Ich bin gegen Tabulatoren! Sobald jemand abweichende Tabstops im Editor einstellt, passt alles nicht mehr zusammen.

"[TABLE_USERS)" sollte auf der ersten Zeile bleiben, da es zum ersten Format gehoert.
Die dritte Zeile wird gegenueber der zweiten Zeile eingerueckt, da sie ja Teil des zweiten Format ist.

Zitat von Pseudemys Nelsoni:

Wie würden die Borlander wohl diese Zeile schreiben?

Das ist wohl nebensaechlich, die schlagen ja auch Spaces anstatt Tabs vor

Meine Meinung: obige Zeile ist - egal wie schoen aufgeteilt - immer noch zu haesslich um in einem Programm zu landen. Da kennt sich ja kein Mensch aus. Ich weiss ja nicht was genau du vorhast, aber wenn moeglich, loese das Zeug mit Paremetern. Diesen zweiten Format-Befehl haelt man ja im Kopf nicht aus. Anstatt immer mit den Indizes beim Format und dem #39 als ersten "Parameter" rumzubasteln, guck dir mal QuotedStr an.

Also ich persoenlich wuerde das so schreiben:

markieren

Delphi-Quellcode:

EncPass := QuotedStr(iif(MD5Pass, MD5DigestToStr(MD5String(_enc(Pass))), _enc(Pass)));
QueryStr := Format('INSERT INTO %s (nickname, password, email, newsletter, shareinfo) ', [TABLE_USERS]);
QueryStr := QueryStr + Format('VALUES (%s, %s, %s, %d, %d)', [QuotedStr(Nick), EncPass, QuotedStr(Mail), Newsletter, ShareInfo]);
Query := PChar(QueryStr);

Ich weiss nicht wie du auf die geniale Idee gekommen bist, Integers in Quotes zu setzen, dies ist in SQL nicht ueblich. Vielmehr solltest du einfach sicherstellen, dass du auch Integers hast (jeder der mal ein Query in PHP zusammengefriemelt hat weiss wovon ich rede).

Greetz
alcaeus

Hilft Dir das weiter?

Fangen wir einen Tabulator gegen Spaces Flamewar an

Nein? Schade

Zitat von Robert Marquardt:

Fangen wir einen Tabulator gegen Spaces Flamewar an

Naja, wir sind da 2 gegen einen und bisher hat sich noch jedes Argument gegen Tabs als Käse entpuppt.
Hast du da etwas handfestes?

ziemlich OT:
Warum erinnert mich das an einen Kommentar aus der Trollhöhle?

Zitat:

There is no need to add gimmicks to Delphi.

Der war mir genauso unsympathisch...

Das Argument gegen Tabs ist das je nach Tab-Einstellung des Users die Source unterschiedlich dargestellt wird.

Bei den Spracherweiterungen landet man am Ende bei so etwas wie C++ das nur noch wenige Experten voll nutzen koennen.
Damit geraten Firmen aber in die Produktivitaetsfalle. Der Job ist mit den tollen Features schneller erledigt,
aber man kriegt keinen der seltenen Experten die es ueberhaupt koennen.

Zitat von Robert Marquardt:

Das Argument gegen Tabs ist das je nach Tab-Einstellung des Users die Source unterschiedlich dargestellt wird.

Umgekehrt wird ein Schuh draus ... (Sagt man das so ?)

Der Vorteil von Tabs ist, dass sie je nach Tab-Einstellung unterschiedlich dargestellt werden, und ich so meinem Partner o.a. nicht meine Einrückweite aufzwinge. Mein Bruder bsw. rückt mit 8 Leerzeichen ein, ich mit 2, wenn wir Tabs benutzen, sieht's jeder, wie er es sehen will