Michał Górny posted on Mon, 01 Sep 2014 12:52:49 +0200 as excerpted: > That said, I suggest the following basic rules:
> 5. Helpers should define both short and long variants for each option > they provide. > Explanation and rationale; > (5) This is pretty much a open field for dicussion. > If developers don't feel like we ought to support both long and short > options, we should probably go for short options only. If it's to be codified I'd suggest requiring long options. After all ebuilds are scripts, and the readability factor mentioned elsewhere counts. Long options are readable options. Years ago I preferred short options in my own scripts. After a few years maintaining them and having to repeatedly lookup what a short option means, I'm seeing the light of long options. Short options are great for interactive or one-offs where you have the manpage right in front of you, but if you or someone else is going to be looking at the script again later, long options rule! =:^) And ebuilds and eclasses should be designed to look at again later. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
