| |
 |
| Perl für Systemadministratoren |
|
|
Veröffentlicht durch maol am Freitag 12. Juli, 13:32
Aus der print-"Abt"-or-die; Abteilung
|
|
|
|
|
Auf dem SAGEwire, dem Symlink der SAGE/Usenix, hat's einen guten Artikel darüber, wie man gutes, lesbares Perl schreibt, und v.a. wie man gewisse angelernte Gewohnheiten mit Perl einfach über den Haufen werfen soll. Die Artikelreihe wird fortgesetzt.
|
|
|
|
< KDE 3 und Otto Normalanwender | Druckausgabe | Soundbug bei den Dealern > | |
|
|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
| |
|
|
|
|
Von Anonymer Feigling am Saturday 13. July, 02:13 MES (#3)
|
|
|
|
|
> When using Perl's builtin functions,
> parentheses should be used to disambiguate,
> not simply as force of habit.
Diese Regel finde ich Unsinn. Man sollte Klammern nicht willkürlich einmal setzen und einmal nicht, frei nach (wohlgemerkt subjektivem) Gutdünken. Stattdessen sollte man sich in erster Linie auf eine *konsistente* Klammersetzung einigen, ob mit oder ohne Klammern.
Beispiel: Ich habe zwei Methoden. Einmal eine mit mehreren, komplizierten Argumenten, einmal eine nur mit einem einzigen, einfachen Argument. Trey Harris würde vermutlich im ersten Fall Klammern setzen, im zweiten nicht. Ich hingegen würde bei *beiden* Klammern setzen, sofern mindestens einer der beiden Fälle durch Klammersetzung verständlicher wird. Wenn nicht, würde ich in *beiden* Fällen keine Klammern setzen.
Ich werte also die objektive Systematik der Syntax und Semantik einer Programmiersprache höher als den subjektiven Entscheid der Klammersetzung.
Grund: M.E. ist eine (Programmier-)Sprache und deren Code umso schwieriger zu verstehen und zu erlernen, je unsystematischer sie aufgebaut ist, je mehr Freiheiten sie lässt.
Meine wichtigste Regel würde also lauten:
"Write consistent, systematic, unambiguous code that beginners can understand easily."
|
|
|
|
|
|
