Quote

Hallo Hrhon,

da steckt eine Menge Arbeit drin - Respekt! Ich habe es nur kurz überflogen. Was mir aufgefallen ist, ist das es sehr klassisch prozedural aufgebaut ist, wogegen nichts spricht. Ich denke du hättest eine größere Übersichtlichkeit erreichen können, wenn du es in Klassen strukturiert hättest.

Ja, es ist wirklich sehr groß geworden. Klassen währen angebracht, allein für die Übersichtlichkeit. Es ist ein typisches Programm, das klein angefangen hat und dann immer größer wurde.
Objektoriniert programmier ich Perl absichtlich nicht. Ich find, dafür ist Perl einfach nicht geschaffen und diese Funktionalität ist irgendwie nur aufgesetzt. Perl hat ganz andere Stärken (zum Beispiel die Stringmanipulation)

Quote

use warnings ist auch immer eine gute idee:

ich weiss, dass da ein haufen warnings kommen :-) hab ich extra ausgeschaltet. Dieses Porgramm ist ja auch nur für mich gedacht und soll an keinen Kunden rausgehen. Wenn jetzt natürlich ein größeres Projekt draus wird, geb ich dir recht, dann gehört das use warnings Pragma wieder rein.

Quote

das sollte kein problem sein. open() kann damit umgehen.
ansonsten ist man immer gut beraten, File::Spec zu benutzen. aber
ich gebe zu, das ist dann deutlich mehr tippaufwand.

Open schon, aber mein Programm nicht. Wenn du dir die README durchließt, wirst du festellen, dass mein Programm nach Taginformationen im Filenamen suchen kann. Der Filename wird dazu nach Verzeichnissen getrennt aufgesplitet. Es ist ja kein großese Thema, mann muss ja lediglich das /- Zeichen durch ein \- Zeichen ersetzen. Ich habs halt nur noch nicht gemacht. Und bevor sich ein WindowsNutzer wundert, warum bei ihm gar nichts geht, hab ich es lieber mal dazugeschrieben.

Quote

sub Help: sorry, aber das ist grausig, auf diese Weise text aneinanderzuhängen.
es gibt da here-docs, siehe perldoc perlop.

Ja, das ist wirklich nicht schön. Eigentlich wollt ich auch noch irgendwann ein POD draus machen, bin aber noch nicht dazugekommen.

Quote

und ich würde wirklich versuchen, das ganze in mehrere klassen
aufzuteilen, muss ja nicht gleich objektorientiert sein, aber 2500 zeilen
ist schon eine ganze menge

(siehe Oben)

Quote

wenn der stil nicht so völlig anders als mein eigener wäre, würd ich mich
vielleicht noch etwas mehr damit beschäftigen. lies mal perldoc perlstyle.
mehr whitespaces, weniger klammern, variablen erst dann deklarieren,
wenn man sie braucht, und 4 spaces zum einrücken (oder auch tabs, aber
ich sehe hier 2 spaces und tabs gemischt. bin vor 1 1/2 jahren von
tabs mit einrückung 2 auf 4 spaces umgestiegen, das ist doch viel
lesbarer.)

ich hatte früher auch einen stil mit mehr Whitespaces und Newlines. Bis mir mal irgendwann ein erfahrener Programmierer erklärt hat, dass er versucht, möglichst viel Code auf möglichst wenig Raum zu packen. Das ist wirklich ein Vorteil, weil man schnell alle Details im Blick hat, ohne viel Scrollen zu müssen (ok, ich machs mir teilweise wieder kaputt, weil meine Funtkionen zu groß sind. Ich versuch zwar, große Problem in möglichst viele kleine Teilprobleme aufzuteilen, bin da aber nicht immer sehr konsequent gewesen, ich weiss)

Ich muss sagen, 2 Spaces sind völlig ausreichend, bei 4 Spaces kommt man doch sehr schnell über das 80 Zeichen Limit pro Zeile (das ist was, woran ich mich versuch, einigermaßen zu halten - leider auch nicht immer 100%ig konsequent. Hat einfach Vorteile, wenn man sich das Prog mal ausdrucken will)
Das mit den Tabs ist ein VIM Problem. Hab den noch nicht so umkonfiguriert, dass er nur mit Spaces arbeitet. Der ersetzt immer 8 aufeinanderfolgende Spaces durch einen Tab. Ich werd bei der nächsten Version mal eine Subsitution über die Code laufen lassen und alle Tabulatoren durch Spaces ersetzen lassen.

Ach ja, und das mit der Variablendeklaration. Eigentlich hab ich meine Variablen möglichst strikt in den Funktionen gehalten und mit my deklariert. Es sind nur die Variablen our, die ich im gesamten Prgramm brauche (viele von den globalen Variablen würden bei einer objektorientierten Gestaltung des Programm wegfallen, eine Funktion kann sich aber leider über den Funtkionsaufruf hinaus keine Zustände merken). Und ich find, es ist guter Programmierstil, wenn man die our-Variablen am Anfang des Programm deklariert. Mit vielen von diesen Variablen kann man das Porgramm doch erheblich in seiner Funktion beeinflussen. Das ist sehr störend, wenn man sich die entsprechenden Variablen erst irgendwo im Code raussuchen muss.
Wahrscheinlich hätte ich eh mehr als die Hälfte der Variablen am Anfang als Konstanten deklarieren sollen, das sind sie nämlich eigentlich, weiss gar nicht, warum ich das nicht gemacht hab.

Gut, aber das sind verschiedene Philosophien. Jeder Programmierer hat da so seine eigenen Macken ;-)


Erst mal Danke für das Feeback. Die meisten Vorschläge sind ja durchaus richtig und wären es eigentlich wert, umgesetzt zu werden. Leider fängt morgen das Sommersemester an, ich werd also ziemlich sicher keine Zeit finden (oder nur ganz wenig) um mich mit dem Programm zu beschäftigen. Vielleicht komm ich ja in den nächsten Semesterferien dazu.
Hab heute das Programm mit etwa 1900 Mp3s mal unter realen Bedinungen getestet. Es hat doch noch erhebliche Mängel und viele Kinderkrankheiten. Ich find die Grundidee von dem Programm gut, aber so wie es jetzt ist, ist es fast noch nicht einsetzbar. Das größte Problem, dass ich noch habe, ist, dass der User zu häufig gefragt wird, welche Taginformationen denn nun verwendet werden sollen. Das rührt daher, weil das Programm die Informationen aus sehr vielen unterschiedlichen Quellen holt und dann jedes mal den Benutzer fragen muss, was denn nun richtig ist. Da dem User aber eigentlich Arbeit abgenommen werden soll führt dieser Weg in die falsche Richtung.
Außerdem ist das Prog dadurch, dass es sogar beim Aufrufen Reguläre Ausdrücke von Perl erwartet, bis jetzt nur für Perl-Kenner geeignet. Auch hier muss noch einiges gefeilt werden, damit es von jedem bedient werden kann.

Mal sehen, wo das Projekt noch hinführt.

wünsch euch einen schönen Abend

Flo