[mcantor]

Oh, and another:

Use your language's command-line option processing libraries.

OptionParser in ruby and argparse in python. There is no reason to eschew these libraries: they're part of the standard library, they require zero coupling to your app logic, and they handle all of the edge cases for free.

"But I can just shift the arguments", you say! Yeah? Great! What if the user pipes input through STDOUT? What if the user passes a flag, a required argument, and then another flag? Will your script read the last flag correctly, or has the naive logic already entered "required argument processing mode"? Just use the library. It's a solved problem!

[reinhardt]

Just use the library. It's a solved problem!

Indeed! In fact it is so solved that the Python standard library has solved it differently 3-4 (I've lost count) times already, let alone the dozen or two extra packages at PyPI ;)

[Goladus]

Yeah most of my scripts use OptParse and I'm procrastinating the rewrite for newer versions of python. I think I may just use getopt, which isn't going anywhere, and roll my own extensions if I need them.

[antoarts]

I choose not to discuss implementation in that article, but you should never reinvent the wheel (poorly).

[mcantor]

I think a lot of people don't even realize such libraries are out there, or don't understand that there's a wheel being reinvented. ("It's just command line options. Why would you need a whole library to do that?")

[_delirium]

Some of the wheels are also very big and crufty--- I would only link GNU Getopt to a C program if it were a Real Program, either with complex option processing or need for industrial-strength polish. For simple one-offs it's a lot easier to have 3 lines of strcmp(), and Getopt feels like overkill.

[scott_s]

And if you use C++ and are willing to use Boost, program_options: http://www.boost.org/doc/libs/1_47_0/doc/html/program_option...

I recognize that many people are not willing to use C++, and among those that are, many are still unwilling to use Boost, but I find the program_options library to be great. An example use that I think is reasonable and a big win over doing it myself: https://github.com/scotts/cellgen/blob/master/src/main.cpp#L...

[huhtenberg]

> many are still* unwilling to use Boost*

I can appreciate the subtlety of wording, but in reality it is more of

> many will never be touching Boost even with a long pole and for a large sum of money

:)

[scott_s]

Yeah, I was thinking of the people who are violently opposed to it. And, man, I have to admit I really don't get that attitude. There are some well-designed libraries in there, and you can pick-and-choose which libraries you want to use.

I respect people's decision, I guess I just don't understand it.

[llimllib]

When I have to compile your program which uses that oh-so-useful Boost library, I curse you to the skies.

[epochwolf]

I haven't used C++ since college so I don't understand why this would be an issue.

[copper]

If you don't have an easy way of installing boost, it becomes complicated - just to compile one program.

That said, boost is a dependency that pays off in terms of programmer time if what you're doing is complicated enough (in other words, if you think you might reimplement some part of boost, you're better off using it as a dependency instead.)

[scott_s]

Boost is installed standard with most Linux distributions now.

[shaggyfrog]

What's the deal with not liking Boost? I've used several of its components off and on over the years.

[brunoc]

I'm working on a CLI right now that's rather "complex" in Ruby and i'm seeing the other extreme: CLI frameworks and DSLs. I don't know about other languages but in Ruby your library options range from the minimal (DIY with OptsParser, Trollop) to the gigantic (Thor, Rubicon) and everything in between...

[billmcneale]

For Java: JCommander http://jcommander.org/