[osandov]

A nitpicky tip: --help is normal execution, not an error, so the usage information should be printed to stdout, not stderr (and it should exit with a successful status). Nothing is more annoying than trying to use a convoluted program with a million flags (which should have a man page in the first place) and piping --help into less with no success.

[grymoire1]

I hate it when a program has a huge --help output, and the man page is nearly empty, and says "see the --help option for more details." Things like examples, see also, etc. are very valuable to someone trying to figure out how to use a program....

[foobarbaz1234]

I am not so sure with that. Say, your program is used in a shell script and is invoked badly - you might want to print its usage then. If you exit normally your shell script might break weirdly but if you exit with error it's easier to spot the reason of failure.

On the other hand you made me thinking and probably you should have three code passes per default:

  [0] normal behaviour (exit 0)
  [1] bad arguments (exit EINVAL)
  [2] --usage (print to stdout but but exit != 0)?

Anyway I am not sure if it makes sense to declare "usage" as normal behaviour.

[Someone]

In my book, there is a difference between explicitly asking for help/usage and passing arguments that do not make sense, which triggers the output of help/usage.

The former, I think, should write to stdout and return 0, the latter should write to stderr and return something non-zero.

Giving help if the user asks for it is normal behaviour.

[pimlottc]

This annoys me to no end. Of course, you can work around it:

    annoying_program 2>&1 | less

but it is very unfriendly to stymie a user's attempt to get help when they're already probably confused.