MP3Tagger: Ein MP3-Tag-Editierungsprogramm (Seite 2) (Projekte)

[thread]4585[/thread]

MP3Tagger: Ein MP3-Tag-Editierungsprogramm (Seite 2)

Leser: 1

2006-04-24 00:44

User since
2003-08-04
12208 Artikel
Admin1

[quote=Hrhon,23.04.2006, 19:25]Was genau stört dich eigentlich an meinem Code.[/quote]
hab ich ja gesagt, und ich hab auch gesagt, dass es sich sehr von
meinem stil unterscheidet und *ich* es deswegen nicht gut lesen kann
und dass du tabs und spaces mischst, und das führt dazu, dass der
code bei anderen leuten merkwürdig aussieht, weil sie tabs anders
eingestellt haben. wenn man tabs benutzt, sollte man das überall tun.

und das sind alles nur vorschläge. weil ich dachte, dass du jemanden
zur zusammenarbeit suchst.

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"
lesen: Wiki:

Wie frage ich & perlintro Wiki:

brian's Leitfaden für jedes Perl-Problem

Hrhon

2006-04-24 01:47

User since
2006-04-22
5 Artikel
BenutzerIn

[quote=pq,23.04.2006, 22:44][quote=Hrhon,23.04.2006, 19:25]Was genau stört dich eigentlich an meinem Code.[/quote]
hab ich ja gesagt, und ich hab auch gesagt, dass es sich sehr von
meinem stil unterscheidet und *ich* es deswegen nicht gut lesen kann
und dass du tabs und spaces mischst, und das führt dazu, dass der
code bei anderen leuten merkwürdig aussieht, weil sie tabs anders
eingestellt haben. wenn man tabs benutzt, sollte man das überall tun.

und das sind alles nur vorschläge. weil ich dachte, dass du jemanden
zur zusammenarbeit suchst.[/quote]

ok streiten wir uns nicht, ich akzeptiere ja, dass jeder seinen eigenen Stil hat und ich setz ja auch gar nicht voraus, dass meiner so perfekt ist ;-) Und mit den Tabs hast du recht, ich hab ja auch schon angeboten, dass bei der nächsten Version nur noch Spaces vorhanden sein werden.

Vorschlag von meiner Seite. Wir lassen jetzt das ganze erst mal so wies ist, ich kümmer mich in meinem knappen Zeitfenster darum, dass der Code einigermaßen ordentlich aussieht (heisst, einheitliches Einrückzeichen - ich werds wahrscheinlich nicht schaffen, den Code komplett umzuschreiben, so dass wieder mehr Leerzeichen drin sind etc.) und ich werd nochmal jede Funtkion ausführlich dokumentieren. Wenn ich das hab, lad ich es hoch und post das hier nochmal. Dann schau ma mal, ob ma was draus machen können. ein erster Schritt wär zum Beispiel, dass Ding zu strukturieren und in Klassen einzuteilen, dann lassen sich nämlich viel besser Aufgaben verteilen (gegen die Klasseneinteilung hab ich nie was gesagt :-)

ich wünsch allen erst mal eine gute Nacht. Ich meld mich dann wieder

Flo

P.S.: Wunder euch nicht, wenns etwas länger dauert. Studium geht leider vor.

Strat

2006-04-24 02:10

User since
2003-08-04
5246 Artikel
ModeratorIn

die folgenden sachen sind mir auf die schnelle aufgefallen:

vielleicht das hauptprogramm noch in mehrere subroutinen aufteilen? du hast da eine Menge an code mit

Code: (dl )

if ( exists $Options{xxxxx}) {
   # ein paar zeilen
  exit 1;
}

eine Subroutine namens CheckProgramParameters oder so koennte da entruempeln, und der leser kapiert schneller, was du da machst

du verwendest eine menge "globaler" variablen (mit our); sind die wirklich alle noetig?

mit der "tabellenschreibweise" koennte es noch etwas besser lesbar werden; und da in den zeichenketten nichts interpoliert wird, wuerde ich da einfache anfuehrungszeichen verwenden, z.B.

Code: (dl )

our %ID3v1Tags = (
                  name             => 'title' ,
                  interpret        => 'artist',
                  album            => 'album' ,
                  erscheinungsjahr => 'year'  ,
                  tracknummer      => 'track' ,
                  genre            => 'genre' ,
              );

Code: (dl )

1
2
3

for (my $id=0;$id<@{$Genres};$id++) {
    $Genres{lc($Genres->[$id])}=$id;
}

mag zwar fuer einen C-Programmierer recht gut lesbar sein, aber ich finde folgendes besser:

Code: (dl )

1
2
3

for my $id (0..$#Genres) {
    $Genres{ lc($Genres->[$id]) } = $id;
} # for

sub Help: wie gefaellt dir:

Code: (dl )

print <<EOH;
Parameter:

  -a | --ask[=tag]         Kombination aus ...
  -A | --All                   Ist diese Option ...
usw.
EOH

eine leerzeile nach jedem gedankengang macht den code meist besser lesbar (z.B. in WriteTags, CheckFrame)

ein paar leerzeichen koennen code auch besser lesbar machen, z.B.

Code: (dl )

1
2
3

$return.=$word.shift @words;
# oder
$return .= $word . shift(@words);

perl -le "s::*erlco'unaty.'.dk':e,y;*kn:ai;penmic;;print"
http://www.fabiani.net/

Hrhon

2006-04-25 01:02

User since
2006-04-22
5 Artikel
BenutzerIn

Hi,

ich hab es jetzt wenigstens mal geschafft, die Einrückungen ordentlich zu machen. Hab mich doch dazu entschlossen, mit Tabulatoren zu arbeiten. Ist im VIM leichter einzustellen. Wenn einer lieber Spaces mag, in Perl ist das ja schnell gescriptet, um sich das übersetzen zu lassen. Hab folgende Code verwendet:

Code: (dl )

#!/usr/bin/perl

open (TAGGER,"<./mp3tagger.pl") || die "Fehler beim Öffnen\n";
@lines=<TAGGER>;
close(TAGGER);

open (WRITE,">./mp3tagger_change.pl") || die "Fehler beim Schreiben\n";
foreach (@lines) {
  s/\t/        /g;
  s/  /\t/g;
  print WRITE $_;
}
close (WRITE);

aber ich denk, das dürfte hier sowieso für niemanden ein Problem darstellen ;-) nur der Vollständigkeit halber.

Die Kommentare müssen leider noch etwas auf sich warten lassen. Ich spiel mit dem Gedanken, POD zu verwenden und dann eine eigene Entwickler Doku und eine eigene User Doku anfertigen zu lassen. Da die Funtkionen sowieso alle dokumentiert sind oder sein müssen, ist das kein Mehraufwand, statt den #-Kommentaren verwendet man halt die POD-Syntax. Ich glaub, ich hab sogwar was gesehen, dass das Getopt Modul mit diesen POD-Stellen umgehen kann. Dann kann man evtl sogar die Doku über help aufteilen lassen (z.b. --help für übersichtliche Doku, --help=long für lange Doku und --help=dev für die Entwicklerdoku). Was haltet ihr davon? Soll ich das so machen, oder lieber auf eines der Module für Textverarbeitung zurückgreifen, dass ihr mir oben empfohlen habt?

@Strat:
Das mit der zusätzlichen Subroutine im Hautprogramm wird ziemlich sicher eh kommen, wenn das gesamte Programm in Klassen aufgeteilt wird.
Die Globalen Variablen sehen auf den ersten Blick nach ner Menge aus, sind aber nahzu fast alle nötig. Viele der Variablen sind eigentlich Konstanten, mit denen man den Programmfluss steuern kann (hab sie nur nicht als solche deklariert) und ein anderer großer Teil sind Variablen, die sich nach dem Aufruf bestimmter Funtkionen global Zustände merken, die ich im Programm auch später noch brauch. Auch dass wird ziemlich sicher etwas übersichtlicher werden, wenn das ding erst mal in Klassen aufgeteilt wird.
Die Geschichte mit den Forschleifen und den Leerzeichen sind diese Philosophien über Programmierstile, die sind wir weiter oben schon durchgegangen.
Auf die Idee mit

Code: (dl )

print <<EOH;

bin ich auch schon gekommen, aber wenn ich jetzt eh mit POD arbeite, dürfte sich auch das Problem erledigen.
Danke auf jeden Fall für dein Feedback

schönen Abend und bis bald

Flo

View all threads created 2006-04-22 23:39.