Hi liebe Community,

folgende Situtaion stellte sich bei mir vor etwa einem Monat. Ich habe einige tausend MP3s auf dem Rechner. Diese sind zwar von der Verzeichnisstruktur her einigermaßen geordnet, aber die Taginformationen sind uner aller sau. Nun habe ich einen IPod, und wie manche von euch sicher wissen, arbeitet das Ituns praktisch nur mit Tag-Informationen. Ihr könnt euch also das Chaos vorstellen, dass ich da vor mir hatte. Ich hab mich also kurzentschlossen hingesetzt, um das Problem mit Perl in den Griff zu bekommen...Und bin dabei auf immer mehr Funtkionen gestoßen, die das Programm unbedingt haben sollte. Es ist bis heute immerhing stolze 2548 Zeilen lang geworden (es war wirklich nicht geplant, so ein Mammutprojekt aus einem eigentlich so kleinem Problem zu machen, aber es stellte sich dann doch schwieriger raus als geplant, so viele Spezialfälle, wie ich sie bei mir vorliegen hab, mit einem Programm zu lösen).
Hab bis jetzt leider nur erste Tests fahren können und bin noch gar nicht recht dazu gekommen, die MP3-Tags nun von meinem Programm aktualisieren zu lassen. Ich kann euch also auch nicht 100% versprechen, dass das Programm alles so tut, wie es soll. Es müssen auch unbdeingt noch einige Funktionalitäten rein, damit es etwas leichter zum handhaben ist (steht auch alles in der README). Trotzdem dacht ich mir, ich stells jetzt einfach mal online und schau, was die Perl-Community so dazu sagt. Würde mich rießig darüber freuen, wenn das Progi einige von euch ausprobieren und vielleicht auch Verbesserungsvorschläge bringen (noch mehr würde ich mich natürlich darüber freuen, wenn sich einige auch noch dazu bereit erklären, diese Projekt mitzugestalten. Ich bin leider ein armer kleiner Physikstudent und meine Zeit, in der sich solche Programmiergeschichten umsetzen lassen, ist sehr beschränkt).
Ach ja, unter Windows läuft das ganze noch nicht, da man da erst mal die Verzeichnistrenner von / auf \ ändern müsste. Wenn einer Lust hat...

So, genug gequasselt. Hier ist noch der Link

http://www.goslich-online.de/mp3tagger/

schönen Abend

Flo

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.
Auf jeden Fall vielen Dank für deine Bereitschaft es hier zu veröffentlichen und weiter viel Erfolg mit deinem Projekt - und viel Spass mit Perl.

Gruss,
Ronnie

use warnings ist auch immer eine gute idee:


edit: und use utf8 kann auch nicht schaden. bei mir kommt sonst buchstabensalat raus.\n\n

<!--EDIT|pq|1145802734-->

[quote=Hrhon,22.04.2006, 21:39]Ach ja, unter Windows läuft das ganze noch nicht, da man da erst mal die Verzeichnistrenner von / auf \ ändern müsste. Wenn einer Lust hat...[/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.\n\n

<!--EDIT|pq|1145802907-->

sub Help: sorry, aber das ist grausig, auf diese Weise text aneinanderzuhängen.
es gibt da here-docs, siehe perlop.
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.
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 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.)

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

ich dachte, du suchst leute, die vielleicht mithelfen. da sollte man sich
so tipps wie perlstyle etc. schon zu herzen nehmen bzw. einfach mal
durchgelesen haben.
ich jedenfalls finde den code ziemlich unleserlich, und die theorie "viel
code auf möglichst wenig platz" halte ich für wesentlich schlechter als
den ansatz "subroutinen möglichst so klein, dass sie in ein standard-
terminalfenster passen", d.h. eine subroutine sollte von der funktionalität
(nicht unbedingt von der anzahl der zeichen) klein gehalten werden.
so hat man jede funktion von anderen abkekapselt und sieht alles,
was man sehen muss, ohne zu scrollen, und doch kann man
leerzeichen zur leserlichkeit einstreuen.
das ist zumindest das, was *ich* von vielen erfahrenen programmierern
höre/lese, mir ist wirklich noch keiner begegnet, der die erste theorie
vertritt.
aber wenn du damit selbst klarkommst und es nicht zu einem öffentlichen projekt machen willst, was schade wäre...\n\n

<!--EDIT|pq|1145811264-->

[quote=Hrhon,23.04.2006, 18:29]

Quote

use warnings ist auch immer eine gute idee:

ich weiss, dass da ein haufen warnings kommen :-) hab ich extra ausgeschaltet.[/quote]
tja, es ist nur so, dass du fehler im programm hast.
zeile 779:

darauf weist dich die warnung hin. an $msg wird nur der erste string
angehängt, nicht der zweite.
warnungen sind häufig der hinweis auf fehler, die du sonst nicht
finden würdest bzw. die du erst durch einen fehler im laufenden
betrieb bemerkst und dann auch noch suchen musst.
benutze warnings, du wirst später dankbar sein =)

bißchen was zu lesen: strict und warnings\n\n

<!--EDIT|pq|1145811625-->

Quote

ich dachte, du suchst leute, die vielleicht mithelfen. da sollte man sich
so tipps wie perlstyle etc. schon zu herzen nehmen bzw. einfach mal
durchgelesen haben.
ich jedenfalls finde den code ziemlich unleserlich, und die theorie "viel
code auf möglichst wenig platz" halte ich für wesentlich schlechter als
den ansatz "subroutinen möglichst so klein, dass sie in ein standard-
terminalfenster passen", d.h. eine subroutine sollte von der funktionalität
(nicht unbedingt von der anzahl der zeichen) klein gehalten werden.
so hat man jede funktion von anderen abkekapselt und sieht alles,
was man sehen muss, ohne zu scrollen, und doch kann man
leerzeichen zur leserlichkeit einstreuen.
das ist zumindest das, was *ich* von vielen erfahrenen programmierern
höre/lese, mir ist wirklich noch keiner begegnet, der die erste theorie
vertritt.
aber wenn du damit selbst klarkommst und es nicht zu einem öffentlichen projekt machen willst, was schade wäre...

die Philosophie möglichst kleine Funtkionen von der Funktionalität her hab ich auch gemeint. Hab ich glaub ich zum großteil, wenn auch nicht immer, umgesetzt.
Was genau stört dich eigentlich an meinem Code. Also dass ich manchmal zu viele Klammern Benutze, weiss ich. Da könnt ich mich evtl einschränken. Aber ansonsten... Ich nehme immer selbsterklärende Variablen, ich erkläre sogar noch die meisten Variablen mit einem kurzen Kommentar, ich schreibe nur einen Befehl pro Zeile (mit Ausnahme von Funktionsaufrufen innerhalb von If-Bedingungen. Aber das dürfte je nicht das große Problem sein) und ich erkläre auch die meisten Funktionen mit einem kurzen Kommentar. Das ist eigentlich schon mehr, als die meisten Programmierer machen. Das einzige, was jetzt etwas anders ist , das sind meine geschweiften Klammern

anstatt



schreib ich


und ich lass halt Lerrzeilen weg. Aber ich geb dir recht, am Anfang fand ich die Schreibweise, die ich jetzt hab auch verreckt und ich dachte, ich gewöhn mich nie dran. Aber mitlerweile find ich sie ok.

Mal sehen, wenn ich Zeit find, les ich mir das Perlstyle-Teil mal durch. Aber die Dinge, die ich oben beschrieben haben, gehören eigentlich eh schon zum guten Programmierstil und ich find, ich halt mich auch im Großen und Ganzen ganz gut daran. Aber irgendwie scheint dir mein Code-Bild wohl überhaupt nicht zuzusagen, frag mich nur, worans liegt...

Quote

darauf weist dich die warnung hin. an $msg wird nur der erste string
angehängt, nicht der zweite.
warnungen sind häufig der hinweis auf fehler, die du sonst nicht
finden würdest bzw. die du erst durch einen fehler im laufenden
betrieb bemerkst und dann auch noch suchen musst.
benutze warnings, du wirst später dankbar sein =)

ok, überredet. Ich arbeite ab jetzt mit warnings :-D

Die Einrückung kann man zur Not mit perltidy -i=4 in den Griff bekommen. Das Argument mit der platzsparenden (schmalen) Einrückung, mit dem Ziel der Übersichtlichkeit, ist in Zeiten faltbarer Codeblöcke (kann vim auch) auch nicht mehr angebracht. Ein

zählt ganze 58 Funktionen, die dann nur noch eingeschränkt selbsterklärend sind. Aber die Gliederung in Klassen hatte ich ja schon empfohlen. Es gibt mittlerweile einige Module im cpan, die OOP in Perl sehr viel schöner machen, als die althergebrachte Variante. Die HERE-Docs sind auf jeden Fall sinnvoll, da sie die Textblöcke im Code leichter lesbar und für dich auch einfacher zu bearbeiten machen. Toll ist das du dir viel Mühe mit Kommentaren gemacht hast, was ich meistens vergesse.\n\n

<!--EDIT|Ronnie|1145816824-->