Nothing drives me up the wall faster than wanting to use a program that has no reason not to work on my platform of choice except for an assumption that could have been avoided with a moment's extra thought.
You pass in a string. Everything else is caught at compile time. Mistyping in a regular expression won't be noticed unless you pay close attention to the output.
When comparing code using a regexp and code using File::Basename, isn't it much more obvious what the code using basename($path) is doing? Yes, you can sit there for a couple of seconds to assure yourself that $path =~ s{.*[\\/]}{} is working correctly. But it's immediately obvious what basename is doing. Self-commenting code is way better than code that needs comments to make it easier to follow.
And then it's also solving the problem in the domain of the problem ("how do I get the basename of a file?") rather than in the domain of the solution ("by getting rid of everything up to, and including, the last delimiter"). This means that when something changes, it should be much more obvious what needs to be changed. It definitely makes things not only more maintainable, in my experience, but also more likely to withstand changes in requirements without actual code changes, or with fewer code changes.
Need I go on? Besides, I think that a regular expression is more like a sledgehammer - it is a huge, powerful, generalised tool. Here we have a screw. You want to use a sledge hammer to drive a screw rather than a screwdriver.
In reply to Re^2: remove directory path
by Tanktalus
in thread remove directory path
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |