On Jul 31, 2013, at 8:35 AM, Tom Browder wrote: > I am working on a proposal for DRY handling of binary program option > descriptions, and one thing I've seen in several programs is use of > multiple characters for the same purpose, e.g., 's' or 'S' for bitmap > size. I would like to propose that such use be prohibited for new > programs and existing programs be modified to eliminate multiple use > characters. In most cases I prefer the lowercase character be kept.
Look forward to reading it. I certainly agree that 1) it's a disorganized inconsistent mess and 2) we don't need duplicate options like -s/-S where they both describe a framebuffer size. ;) A few more conventions I'd like to see codified: size options, debug options, help options, tolerance options, input/output options, key/value options, and toggle options. There is a case to be made for uppercase/lowercase options on toggle switches where lower is usually on and upper toggles off. That's useful in cases where the default behavior is variable or indeterminate and you need to ensure something is on/off. Using two letters that would be conflicting if both specified seems less desirable in that situation. Take an example of the tree command where say we want options to output extra information but only for some objects. We might end up with -r to enable extra output for region objects and -R would disable extra output. Default might be one or the other or a third option altogether (like just special decoration). Related effort in this area, Carl Moore has been working on options as well now (for many months). His focus of late has been going through all commands to make sure they all provide help options consistently. This required changing some tools that used -h for "height" for example, where now all commands should be responding with a help/usage statement. His work raises another potential exception to a multiple-character rule (or at least it's something worth discussing) where he's currently making both -? and -h provide help/usage. Presently, they return the same information, but the long-term intent is to make them return *different* levels/types of help information. If they're asking for help, most users guess at conventional options (like -h or --help or -?), so I think it improves usability / approachability so it's good to cover more than one, but then we can also purpose them differently. This could be as simple as one providing usage and the other displaying more descriptive help. An example of two-level help can be seen with the benchmark command (the help and instructions subcommands), though that tool avoids options altogether and goes the subcommand route like many mged commands. Cheers! Sean ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
