note
Aristotle
<p>Ah, so you are talking about long options. Thanks for clearing that up. I have two responses:</p>
<ol><li>
<p>I disagree with the premise.</p>
<p>Sure, in interactive use, long options are pointless.</p>
<p>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.</p>
<p>Yes, long options aren’t <em>necessarily</em> 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.</p>
</li><li>
<p>[doc://Getopt::Long] can parse short options too. Once upon a time it could not (which led to [cpan://Getopt::Mixed]), but that hasn’t been the case in forever.</p>
<p>Why would one do that? Because the API is much better:</p>
<ul>
<li><p>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.</p></li>
<li><p>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.</p></li>
</ul>
</li></ol>
<p align="right" class="pmsig pmsig-114691"><i>Makeshifts last the longest.</i></p>
687283
691381