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