Opened by Hrhon at 2006-04-22 23:39
User since
2006-04-22
5 Artikel
BenutzerIn
![[Homepage]](/battie/theme/default/homepage.gif)
![[default_avatar]](/battie/theme/default/default_avatar.gif)
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:
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
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
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
)
1
2
3
4
5
6
7
8
9
10
11
12
13
#!/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;
Danke auf jeden Fall für dein Feedback
schönen Abend und bis bald
Flo