Font
[thread]7287[/thread]

Forum selber schreiben (page 4)

Readers: 2


<< |< 1 2 3 4 >| >> 36 entries, 4 pages
Magic
 2005-09-27 16:23
#58151 #58151
User since
2003-09-30
91 articles
BenutzerIn
[Homepage] [default_avatar]
[quote=Taulmarill,27.09.2005, 13:48]jeder, der das anders machen will, sollte entweder einen guten grund dafür haben, oder sich damit abfinden, dass er alles alleine machen muss, weil sich keiner in seinem code zurecht findet.[/quote]
ist ja genau mein reden...
Es ist alles erlaubt, solang der Code sauber, übersichtlich und verständlich bleibt. Das ist die Grundvoraussetzung und gilt im Prinzip für jede Sprache, nicht nur Perl.
Wer im Projekt mit anderen zusammenarbeitet muss sich dann halt an die Projektvorgaben halten.

Im Guten und Ganzen gilt aber: "An ein paar Grundregeln sollte man sich halten, andere Regeln dürfen halt auch schon mal etwas anders, freier, ausgelegt werden"
Ein Weiser gibt nicht die richtigen Antworten, sondern er stellt die richtigen Fragen.
Taulmarill
 2005-09-27 16:56
#58152 #58152
User since
2004-02-19
1750 articles
BenutzerIn

user image
imho ist Perl Best Practices durchaus als programmier-richtlinie zu gebrauchen. ich wollte das eigendlich schon bei uns einführen, da wir schon mal externe programmierer für ein paar monate beschäftigen (projektabhängig). da währe es gut, wenn man den leuten vorgaben machen kann.

falls ich demnächst dafür mal ein wenig zeit bekomme, werd ich aus dem buch mal die wichtigsten sachen als firmeninternen projektleitfaden herausdestilieren. aber für so was will einem ja immer keiner zeit geben...
$_=unpack"B*",~pack"H*",$_ and y&1|0& |#&&print"$_\n"for@.=qw BFA2F7C39139F45F78
0A28104594444504400 0A2F107D54447DE7800 0A2110453444450500 73CF1045138445F4800 0
F3EF2044E3D17DE 8A08A0451412411 F3CF207DF41C79E 820A20451412414 83E93C4513D17D2B
Strat
 2005-09-27 20:02
#58153 #58153
User since
2003-08-04
5246 articles
ModeratorIn
[Homepage] [default_avatar]
ich bevorzuge bei groesseren Anwendungen den Weg:
x) kurze hauptprogramme (sind meistens unter 100 Zeilen)
x) Code nach Thematik/Interfaces gruppiert in Module auslagern
x) Pro Funktion/Methode moeglichst nur ein Gedankengang, der sich ueber den Subroutinennamen klassifizieren laesst (allerdings mache ich das nicht 100% konsistent). Dabei komme ich mit 25 Zeilen nur selten hin, gerade wenn ich darin komplexere Datenstrukturen dokumentieren muss. Ich finde auch, die 25-Zeilen-Regel hat mal Sinn gemacht, als die Monitore noch kleiner waren; heutzutage finde ich das eher sinnlos (ok, Subs ueber 100 zeilen verwende ich nur in Ausnahmefaellen)
x) Die Breite von 80 zeichen halte ich - seit ich programmiere - streng ein, obwohl ich nicht genau weiss warum: ich drucke fast nie Code aus, von der Bildschirmgroesse her waeren auch 120 zeichen kein thema, und wenn ich code per mail versende, dann versende ich ihn als attachment. Ich finde es halt so besser lesbar.
x) Sprechende Variablen/Funktionsnamen sind mir sehr wichtig. Ich habe mich dazu entschlossen, die stets auf Englisch zu benennen, als ich mal ein recht langes Script auf Portugisisch debuggen durfte...
x) strict und warnings (wobei ich mittlerweile so arrogant geworden bin und warnings auch in Produktionscode aktiviert lasse). Ich muss dann halt manchmal einige Klimmzuege unternehmen, damit manch "sinnlose" warnings nicht auftreten koennen, wie z.B. bei @x = qw(1 2 3 # a b c , A B C); (PS: ich freue mich schon auf die Perl6-Operatoren // und //= )
perl -le "s::*erlco'unaty.'.dk':e,y;*kn:ai;penmic;;print"
http://www.fabiani.net/
sri
 2005-09-27 21:12
#58154 #58154
User since
2004-01-29
828 articles
BenutzerIn
[Homepage] [default_avatar]
[quote=Strat,27.09.2005, 18:02]ich bevorzuge bei groesseren Anwendungen den Weg:
x) Pro Funktion/Methode moeglichst nur ein Gedankengang, der sich ueber den Subroutinennamen klassifizieren laesst (allerdings mache ich das nicht 100% konsistent). Dabei komme ich mit 25 Zeilen nur selten hin, gerade wenn ich darin komplexere Datenstrukturen dokumentieren muss. Ich finde auch, die 25-Zeilen-Regel hat mal Sinn gemacht, als die Monitore noch kleiner waren; heutzutage finde ich das eher sinnlos (ok, Subs ueber 100 zeilen verwende ich nur in Ausnahmefaellen)
[/quote]
Aber du versuchst sie moeglichst kurz zu halten und weisst genau warum du mehr als 24 brauchst! ;)
[quote=Strat,27.09.2005, 18:02]
x) Die Breite von 80 zeichen halte ich - seit ich programmiere - streng ein, obwohl ich nicht genau weiss warum: ich drucke fast nie Code aus, von der Bildschirmgroesse her waeren auch 120 zeichen kein thema, und wenn ich code per mail versende, dann versende ich ihn als attachment. Ich finde es halt so besser lesbar.
[/quote]
Ich benutze Vim meist im Terminal, deshalb wuerde ich nie mit jemandem arbeiten der diese Regel nicht einhaelt
sri
 2005-09-27 21:24
#58155 #58155
User since
2004-01-29
828 articles
BenutzerIn
[Homepage] [default_avatar]
[quote=Magic,27.09.2005, 10:40]24 Zeilen pro Funktion? Das ist aber sehr unrealistisch, wenn eine Funktion mehr als nur eine Aufgabe durchführen sollen.
[/quote]
Schlechtes design, denn eine Methode/Funktion sollte genau eine Aufgabe haben.
[quote=Magic,27.09.2005, 10:40]
PS: Ich kenne genug Programmierer, ob nun richtig studierte Informatiker über selbstständige Anwendungsentwickler bis zum Hobbyprogrammierer, jeder machts wie er am liebsten hat...[/quote]
Ich kenne genug "top-notch" Programmierer die genau wissen warum ein paar Regeln und Best Practices sehr wichtig sind....
Crian
 2005-09-28 16:31
#58156 #58156
User since
2003-08-04
5867 articles
ModeratorIn
[Homepage]
user image
Ich versuche nach Möglichkeit, Hauptprogramme sehr kurz sein zu lassen, Funktionen wirklich nur eine Sache machen zu lassen, die dann aus dem Namen wenigstens noch halbwegs ersichtlich ist und Funktionen natürlich nicht zu lang werden zu lassen.

Was zu lang ist und was zu kurz, ist dabei eine Sache des Gefühls für den Code.

Meistens ist es aber so, dass "zu lange" Funktionen immer beim Betrachten ein schlechtes Gewissen verursachen, auch wenn es gut begründet und wirklich sinnvoll ist.

Was man nicht machen sollte, ist sich exakt sklawisch an Vorgaben zu halten. Ich kommentiere viel. Wenn jede Funktion nur 24 Zeilen hätte, wären darin vielleicht 5-10 Zeilen echtem Code ...

An die 80 Spalten Regel halte ich mich auch (bis auf Ausnahmen), wobei ich mich auch immer wieder frage, warum eigentlich. Aber sri hat mir gerade ein neues Argument geliefert. (Wobei ich mich frage, warum Du nur 80 Spalten im Terminal hast, sri...)
s--Pevna-;s.([a-z]).chr((ord($1)-84)%26+97).gee; s^([A-Z])^chr((ord($1)-52)%26+65)^gee;print;

use strict; use warnings; Link zu meiner Perlseite
<< |< 1 2 3 4 >| >> 36 entries, 4 pages



View all threads created 2005-09-18 19:50.