in reply to
Re^7: Use Getopt::Long even if you don't think you need to
in thread Use Getopt::Long even if you don't think you need to
Ah, so you are talking about long options. Thanks for clearing that up. I have two responses:
I disagree with the premise.
Sure, in interactive use, long options are pointless.
However, I also write shell scripts on occasion, and then it is quite useful to use the long options of a command I donít use routinely, as it makes it quicker to re-read the script when I open it again 2 years from now. Trying to avoid writing comments whenever it is possible to make the code sufficiently self-descriptive is a strategy thatís served me excellently in general.
Yes, long options arenít necessarily any more self-explanatory than short ones. But that depends on the scope and focus of the tool; if it does one thing well, more likely than not you can choose useful names for long options.
Getopt::Long can parse short options too. Once upon a time it could not (which led to Getopt::Mixed), but that hasnít been the case in forever.
Why would one do that? Because the API is much better:
It allows much more specific declaration of the values a switch can take. This means I can write less code Ė and if itís just validating whether the argument the user actually passed is a number when I need a number.
It allows stashing values in arbitrarily named variables rather than just a hash with single-letter keys. I donít know about you, but I find my programs more readable when my variables have useful names.
Makeshifts last the longest.