|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: mp3 collection renamer
by abstracts (Hermit) on Apr 28, 2002 at 08:50 UTC | |
And one more final thing which is more important than all of the above blabbering: do "perl name.pl '-' ARTIST" and wonder why all your artists suddenly have one song each. Or worse: Watch all your mp3s reduced to a singleton ".mp3" as you forget to pass args other than the sep!!. Hope this helps!! | [reply] [d/l] |
|
Re: mp3 collection renamer
by boo_radley (Parson) on Apr 28, 2002 at 18:20 UTC | |
Firstly : This is valid, but klunky perl. As I just went through the process of working with my own MP3 collection, I recommend using the tag object in hash form (I eventually went to tagged because I was rewriting id3v2 tags, but that's another story entirely). This is probably frowned upon by OOP purists, but we're all friends here. Here's a short example comparing the two methods. If this isn't clear, any time an object uses a hash to store data, you can (usually, unless the module author was clever) access that hash by typecasting the instantiation of that object into a hash. Well, what does that mean? it means that if we have a $tag object, we can treat it like a simple hash like so : %$tag. OK. We've just reduced 6 lines of code to 1; that's a pretty good deal. There's less to troubleshoot, comment and the meaning of the code becomes clearer. Secondly : print "Renamed $_ to $nn \n" if rename $_,$nn; This is terrible! When renaming files, you should always check to see if the file exists beforehand! Always! Well, usually, and certainly in this case. I don't want to have to re-rip a cd because, this script renamed 32 mp3s to "WARLOCK PINCHERS.mp3" after only inputting the artist on the command line! I like to use unless in these cases, when I'm expecting (but still not sure!) that the file will not already exist.
Those are my concerns. Overall, I don't think this is entirely a bad script; it's probably one that you hacked together after saying "my mp3 collection, it's a damn mess!", and whipped together something immediately useful to you. Whenever you share things on perlmonks, it becomes a more public thing, though, and just as you pretty up to go out on the town, you should pretty up your code when you show it off on perlmonks. Comment things excessively. Your script requires command line parameters? Think about using Getopt::Long, or at least checking for a sane number of params. Did you examine a particular algorithm, found it lacking and developed a new strategy for the same task? Say so in your comments. When you're done with the script, go back and say,"What can I improve? What does not inherently make sense to me that I can change?".The quality and nature of your coding will improve when you start to actively think about it. | [reply] [d/l] [select] |
by demerphq (Chancellor) on May 02, 2002 at 10:14 UTC | |
But a minor pedantic point: If this isn't clear, any time an object uses a hash to store data, you can (usually, unless the module author was clever) access that hash by typecasting the instantiation of that object into a hash. I'm guessing that the above was just poor choice of words but just in case a newbie reads it I wanted to clear up what appears to be a bit of confusion. What you really mean is that any time an objects underlying data type is a hash then it can be manipulated just like a reference to a normal hash, ( there is no casting involved). In fact due to the fact that object types in perl are orthogonal from the their data type (despite what ref() says) this statement can be generalized to say that an object reference can always be treated exactly the same as a reference to the underlying data type. The clever bit only means that the author has used an underlying datatype (I'm guessing you meant CODE refs) that prevents introspection. Anyway, as I said good review.
Yves / DeMerphq | [reply] |
| |