Revision ec63079e
Von Sven Schöling vor mehr als 15 Jahren hinzugefügt
| doc/programmierstilrichtlinien.txt | ||
|---|---|---|
|
|
||
|
Diese Regeln sind keine Schikane, sondern erleichtern allen das Leben!
|
||
|
|
||
|
Jeder, der einen Patch schickt, sollte sein Script vorher durch perltidy
|
||
|
laufen lassen. Damit werden einige der nachfolgenden Regeln automatisch
|
||
|
befolgt, andere hingegen nicht. Dort, wo keine perltidy-Optionen angegeben
|
||
|
sind, muss der Programmierer selbst f?r die Einhaltung sorgen.
|
||
|
Jeder, der einen Patch schickt, sollte seinen Code vorher ?berpr?fen.
|
||
|
Einige der Regeln lassen sich automatisch ?berpr?fen, andere nicht.
|
||
|
|
||
|
--------------------------------------------------------------------------
|
||
|
|
||
| ... | ... | |
|
$form->{"row_$i"} = $form->{"row_$i"} - 5;
|
||
|
$some_hash{42} = 54;
|
||
|
|
||
|
11. Die Maximale Zeilenl?nge ist nicht bescr?nkt. Zeilenl?ngen <= 79
|
||
|
11. Die maximale Zeilenl?nge ist nicht bescr?nkt. Zeilenl?ngen <= 79
|
||
|
helfen unter bestimmten Bedingungen, aber wenn die Lesbarkeit unter
|
||
|
kurzen Zeilen leidet (wie zum Biespiel in grossen Tabellen), dann
|
||
|
ist Lesbarkeit vorzuziehen.
|
||
| ... | ... | |
|
12. Trailing Whitespace, d.h. Leerzeichen am Ende von Zeilen sind unerw?nscht.
|
||
|
Sie f?hren zu unn?tigen Whitespace?nderungen die diffs verf?lschen.
|
||
|
|
||
|
Emacs und vim haben beide recht einfach Methoden daf?r:
|
||
|
Emacs und vim haben beide recht einfache Methoden daf?r:
|
||
|
emacs kennt das Kommande nuke-trailing-whitespace,
|
||
|
vim macht das gleiche manuell ?ber :%s/\s\+$//e
|
||
|
vim macht das gleiche manuell ?ber :%s/\s\+$//e, mit
|
||
|
:au BufWritePre * :%s/\s\+$//e
|
||
|
wird das an speichern gebunden.
|
||
|
|
||
|
12. Es wird kein perltidy verwendet.
|
||
|
|
||
|
In der Vergangenheit wurde versucht perltidy zu verwenden um einen
|
||
|
einheitlichen Stil zu erlangen, es hat sich aber gezeigt, dass Perltidys
|
||
|
sehr eigenwilliges Verhaltes was Zeilenumbr?che angeht oftmals gut
|
||
|
formatierten Code zerst?rt. F?r den Interessierten, hier sind die perltidy
|
||
|
Optionen die grob den beschriebenen Richtlinien entsprechen.
|
||
|
|
||
|
-syn
|
||
|
-i=2
|
||
|
-nt
|
||
|
-pt=2
|
||
|
-sbt=2
|
||
|
-ci=2
|
||
|
-ibc
|
||
|
-hsc
|
||
|
-noll
|
||
|
-nsts
|
||
|
-nsfs
|
||
|
-asc
|
||
|
-dsm
|
||
|
-aws
|
||
|
-bbc
|
||
|
-bbs
|
||
|
-bbb
|
||
|
-mbl=1
|
||
|
-nsob
|
||
|
-ce
|
||
|
-nbl
|
||
|
-nsbl
|
||
|
-cti=0
|
||
|
-bbt=0
|
||
|
-bar
|
||
|
-l=79
|
||
|
-lp
|
||
|
-vt=1
|
||
|
-vtc=1
|
||
|
formatierten Code zerst?rt. F?r den Interessierten sind hier die perltidy
|
||
|
Optionen, die grob den beschriebenen Richtlinien entsprechen.
|
||
|
|
||
|
-syn -i=2 -nt -pt=2 -sbt=2 -ci=2 -ibc -hsc -noll -nsts -nsfs -asc -dsm
|
||
|
-aws -bbc -bbs -bbb -mbl=1 -nsob -ce -nbl -nsbl -cti=0 -bbt=0 -bar -l=79
|
||
|
-lp -vt=1 -vtc=1
|
||
|
|
||
|
13. STDERR ist tabu. Unkonditionale Debugmeldungen auch.
|
||
|
|
||
|
Lx-Office bietet mit dem LXDebug Modul einen brauchbaren Trace/Debug
|
||
|
Mechanismus, es gibt also keinen Grund nach STDERR zu schreiben.
|
||
|
|
||
|
Die LXDebug Methode "message" nimmt als ersten Paramter au?erdem eine
|
||
|
Flagmaske, f?r die die Meldung angezeigt wird, wobei "0" immer angezeigt
|
||
|
wird. Sollte Meldungen sollten nicht eingecheckt werden, und werden in den
|
||
|
meisten F?llen auch vom Repository zur?ckgewiesen.
|
||
Auch abrufbar als: Unified diff
Update Programmierrichtlinien