[quote=Magic,26.09.2005, 19:45]Der Wartung halber habe ich lieber ein großes Script genommen, statt mich bei jedem Fehler durch hunderte von modulen suchen zu müssen.[/quote]
oh oh...

Quote

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
--Damian Conway in "Perl Best Practices"

Ich habe da mal gehört, gute Perl-Skripte hätten 10 Zeilen.

Die ersten 8 sind use-Statements, dann folgt
1 Zeile Kommentar, was das Skript tut, und dann folgt
1 Zeile Code.

Sind auch alles gute Argumente. Ich persönlich denke, dass jeder da seinen eigenen Stil hat.
Ein gut kommentiertes und mit Aussagekräftigen Variablen versehenes 100.000 Zeilen Programm ist mir lieber als ein ein kleines Programm mit 50 verschiedenen, von einander abhängigen und schlecht dokumentierten Modulen.

Im Falle des Forums könnte ich jede einzelne Funktion (ca. 40 sind es) auch mit wenig Aufwand (Viele Funktionen arbeiten authark) in ein eigenes Modul kloppen, nur müssten die Hälfte der Module wieder ineinander verschachtelten werden um die notwendigen Abhängigkeiten zu erfüllen.
Und das ist mir dann wieder zuviel Aufwand... ;o)\n\n

<!--EDIT|Magic|1127763440-->

Um Magic mal zu verteidigen:
Es soll da so Leute geben(was? wer? ich?), die, als sie mit Perl angefangen haben, ein Forum(RPG) mit ~5000 Zeilen Code als ein einziges Programm geschrieben haben und das dann auch noch bis zur Verwendbarkeit debuggt haben. Nur schade dass es nicht mehr genutzt wird da der NPC keine Lust mehr hat. Wer sichs mal ansehen mag:
http://jemand.thefreebizhost.com/cgi-bin/frpg/frpg.cgi

Was ich heute anders machen würde:
- Templatesystem(schrecklich wenn jede Fehlermeldung anders aussieht)
- Bessere Datenspeicherung(war als CVS gemacht und nicht wirklich übersichtlich)
- mehr in Module auslagern(bis man immer bis zu der richtigen Zeile scrollt, um zu merken dass der Fehler in der Subroutine von vor 500 Zeilen liegt)
- besseres Design(im IE sind keine Tabellenränder zu sehen; wie komm ich eigentlich dazu Tabellen zu verwenden?)
- schneller programmieren(mit 6Monaten hat's aber eigentlich gar nichts so lang gedauert, aber jetzt wo ich viel mehr Erfahrungen mit Perl gesammelt hab wäre das wohl wirklich viel schneller machbar)

Hmmm...

5500 Zeilen / 40 Funktionen = 137 Zeilen pro Funktion

Es gibt da so eine nette Regel nach der eine Funktion nur mit guter Begruendung (fuer jeden Einzelfall) mehr als 24 Zeilen haben darf.
Ich persoehnlich halte sehr viel davon da es meist genau das mittelmass zwischen zu viel und zu wenig abstraktion ist. ;)

24 Zeilen pro Funktion? Das ist aber sehr unrealistisch, wenn eine Funktion mehr als nur eine Aufgabe durchführen sollen.
Das funktioniert schon nicht wenn eine Funktion z.B. einen Text aufbereitet und dann je, nach Aufruf, den aufbereiteten Text z.B. speichern, ersetzen, mit der Datenbank abgleichen, aus der Datenbank löschen oder was ganz lustiges machen soll. Da würde man sich durch das auslagern in subs (z.B. das speichern des Textes in einer Textdatei) mehr arbeit machen und ein unübersichtliches Subroutinenchaos aufbauen.

Bei kleineren Scripten wie einem Formmailer oder einem Gästebuch mag das aber auf jeden Fall zutreffen. Da wäre ein 400 Zeilenskript mit 2 Funktionen sicherlich nicht angebracht und unübersichtlicher als 400 Zeilen mit 20 akribisch slbsterklärend benannten Funktionen.

Persönlich halte ich es so, dass ich nur dann eine sub erstelle, wenn diese auch wenigstens 2 mal im script an unterschiedlichen Stellen Verwendung findet, ooooder aber die Übersichtlichkeit enorm steigert.

Trotzdem denke ich aber, dass es sich bei der Frage wieviele Zeilen eine Funktion haben sollte und ob man überhaupt für etwas eine Funktion schreibt, eher um die persönlichen Vorlieben des Programmieres, denn um eine wirkliche Frage des programmierens handelt. Abstraktion ist immer nur solange gut und von Vorteil, wie man die gesamte Abstraktionsschicht noch transparent genug halten kann um auch 2 Jahre später noch durch den Code durchzublicken ohne vorher einen Abend lang die Kommentare im Kot ;o) durchzulesen.
Schätze, dass ist wie mit der dokumentation von Code: Wenn der Code nur für einen selber oder aber selbsterklärend ist, muss man ihn nicht unbedingt so kommentieren, dass ihn auch der Penner an der Bude beim morgentlichen Bier versteht.
Alles Geschmackssache, solang die Geschwindigkeit und Funktion des Programmes nicht beeinträchtigt wird!

Wie seht Ihr das, bzw. wie macht Ihr das?

PS: Ich kenne genug Programmierer, ob nun richtig studierte Informatiker über selbstständige Anwendungsentwickler bis zum Hobbyprogrammierer, jeder machts wie er am liebsten hat...\n\n

<!--EDIT|Magic|1127810740-->

Ich gliedere es meist so, dass je Aufgabe mind. eine Methode erstellt wird. Was auch nur ansatzweise an mehreren Stellen benötigt wird, wird ebenfalls in eine Sub ausgelagert.

[quote=renee,27.09.2005, 10:47]Ich gliedere es meist so, dass je Aufgabe mind. eine Methode erstellt wird. Was auch nur ansatzweise an mehreren Stellen benötigt wird, wird ebenfalls in eine Sub ausgelagert.[/quote]
Im Prinzip mache ich das genauso...
Im Falle des Forums habe ich der einfachheithalber ersteinmal alles in ein großes Script gepackt und werde dann halt, wenn ich Zeit und Lust habe, jeweils zusammengehörige Aufgabengruppen wie z.B. die Subs für die Konfigurationsklamotten als Modul auslagern.

EDIT:

Mit großen Skripten zu arbeiten ist eigentlich gar kein Problem, solang man die richtige Entwicklungsumgebung/Editor benutzt.\n\n

<!--EDIT|Magic|1127812556-->

[quote=Magic,27.09.2005, 10:40]Alles Geschmackssache, solang die Geschwindigkeit und Funktion des Programmes nicht beeinträchtigt wird![/quote]
eben nicht.

Quote

Wie seht Ihr das, bzw. wie macht Ihr das?

so, dass es jemand anderes auch verstehen kann, und zu jemand anderem
zähle ich auch mich selbst in einem halben jahr. (Perl Best Practices)
lies mal das buch, es lohnt sich wirklich.

ich stimme pq zu. "jeder so wie er es für richtig hält" funktioniert bei kleinen scripten. bei grösseren programmen geht das nur viel zu sehr auf die wartbarkeit. ich habe einen kollegen, der ein browserspiel nach ähnlicher mehtode ("alles so wie es gerade passt") programmiert hat, da findet keiner mehr durch und mit jeder neuen funktion die er einbauen will wird's komplizierter.

ich weiss das viele das nicht aktzeptieren wollen, aber einige techniken und methoden haben sich über die jahre einfach als gut und richtig etabliert. 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.