So viele Gedanken mach ich mir da nicht, aber ich glaube, dass
ich auch nichts in dieser Form schreiben würde:

Aber das liegt warscheinlich auch eher daran, dass es total
unleserlich ist. ;)

MfG. Matze

[quote=master,24.04.2006, 14:31]Ausnahmen: Fremdcode, nicht so wichtigen Stellen oder wenn eine Zuweisung recht kurz sein soll.
[/quote]
Wohle eher

$a = 1 if ($a =~ /^\d+$/ && $b =~ /^\w+$/ && $c =~ /^ja$/i && ($d =~ /^1$/ || $e =~ /^1$/));
Soll man sowieso nicht nehmen. Außer die ProgrammeirerIn ist "very, very lazy!"
and anstatt &&.

Quote

Use the new ``and'' and ``or'' operators to avoid having to parenthesize list operators so much, and to reduce the incidence of punctuation operators like && and ||. Call your subroutines as if they were functions or list operators to avoid excessive ampersands and parentheses.

perlstyle
Das sagt sebst der Perl Styleguide ;)\n\n

<!--EDIT|GwenDragon|1145886807-->

Wenn wir das schon wiederaufkochen: Ich benutze auch durchgängig Variante 3, mit "cuddled elses".

Was mich beim Lesen interessiert, ist der Programmablauf und wo er durch Bedingungen oder Schleifen beeinflusst wird.

Durch eine Einrückung erkenne ich, dass dieser Programmabschnitt nicht einfach sequenziell durchlaufen wird, sondern eine Unterbrechung erfährt.
Was diese Unterbrechung verursacht hat, möchte ich gerne in der Zeile über der Einrückung sehen: Das "if", das "while", das "foreach" oder was auch immer.

Wo diese Unterbrechung zu Ende ist, sehe ich eigentlich durch das Ende der Einrückung. Und für Python-Programmierer reicht das sogar.
Die meisten anderen Sprachen haben aber eine zusätzliche Markierung, z.B. eine Endemarkierung für den unterbrechenden Befehl, wie "if ... fi" oder "while ... endwhile", oder Blockmarken wie "{ ... }" oder "begin ... end".

Ich bevorzuge es, wenn so eine Unterbrechung eben nur durch eine Zeile davor (die mit der Bedingung oder dem Schleifenbefehl, evtl. auch dem "else") und eine dahinter "umrahmt" wird. Eine eigene Zeile für die Blockmarke finde ich überflüssig und habe ich mir abgewöhnt, als ich mit Modula-2 aufgehört habe.

Über nichts läßt sich so endlos debattieren wie über Programmierstil (und über den "richtigen" Editor).

Ich bevorzuge klar Variante 1, denn sie ist eine gute Mischung aus Kompaktheit und Übersichtlichkeit :)

Greetz, Doc\n\n

<!--EDIT|docsnyder|1145887187-->

[quote=sid burn,24.04.2006, 10:59]Irgendwie verstehe ich deine Sichtweise nicht so ganz.
Wenn ich, ebenfalls mit einer Regex, überprüfe ob der Benutzer Bereits existiert, dann kann ich kein Benutzer "betterworld\n" anlegen, da es ja das selbe wäre wie "betterworld". Und ich würde eine Meldung bekommen das der benutzer bereits existiert.

Und sagen wir mal man unterscheidet das registrieren mit einem "\n". Dann sehe ich da immer noch keine Probleme. Da es nun in der Datenbank 2 Benutzer gibt. Einmal "betterworld" und einmal "betterworld\n". Wenn ich mein SQL Query dann abschicke hole ich mir entweder das Passwort von "betterworld" oder "betterworld\n", dass jeweils ein unterschiedliches Passwort wäre. Ich könnte also auch nicht das Passwort von "betterworld\n" benutzen um mich mit "betterworld" einloggen.

Zum anderen muss ich auch gar nicht irgendein Benutzername vergleichen. Warum auch? Den Benutzername brauche ich lediglich um das Passwort zu holen, und ich vergleiche danach das Passwort.

Zum anderen sollte es aber Generell ungewollt sein, wenn \n auf einer Website zu den akzeptierten zeichen gehört. Solche Zeichen sollte man bei der Eingabe eigentlich nicht erlauben.[/quote]
Da hast natuerlich recht. Ich will auch nicht behaupten, dass die Benutzerueberpruefung, die ich oben gepostet hatte, sehr sinnvoll programmiert ist oder buchstäblich aus einem existenten Forum entnommen ist. Ich wollte nur zeigen, wie man durch unachtsames Benutzen von $ Sicherheitsluecken (oder auch andere Bugs) einbauen kann.

[quote=jan,12.09.2003, 21:04]ui ui ui, und da redet man immer so viel von den flexiblen perlprogrammieren....[/quote]
soso, und ich dachte immer, da perl eh so flexibel ist, kann man als perl-programmierer voellig unflexibel sein... vielleicht sollte ich mal wieder die sprache wechseln...

Zu diesem und vielen weiteren Themen empfehle das Buch "Perl Best Practises" von D. Conway; auch wenn ich nicht jede Regel wirklich 100% unterschreiben wuerde, finde ich, es sind hervorragende ideen darin, von denen ich einige uebernommen habe, und ich habe daraus auch einiges gelernt (z.B. hat mich Perl's use constant schon lange genervt, und seit der lektuere dieses Buches verwende ich mit viel Freude Readonly)

@GwenDragon
ich nutzt NUR && und || "or" "and" ist mir zu "normal"

zudem auch "eq" und "ne" statt der äquivalenten form..
macht der gewohnheit.

warum(auf deutsch) sollte ich weniger "&&" nutzen?

klar ist besser betreffend sprachenunabhängigkeit
and und or zu nutzen.

Ein Unterschied macht dieses Beispiel deutlich:

[quote=master,24.04.2006, 18:03]zudem auch "eq" und "ne" statt der äquivalenten form..[/quote]
Äh ... welche "äquivalente Form"? ???