Follow the Conventions Users Already Know
The Unix ecosystem has decades of established conventions. When your tool violates them, users have to re-learn your tool's quirks instead of applying what they already know. Conforming to conventions is not just politeness — it's a usability multiplier.
Convention 1: Provide Both Short and Long Flags
Whenever possible, provide both forms. Use long flags in automated scripts for readability (--force, --dry-run) and short flags for interactive shell use (-f, -n). The mapping should be intuitive: --verbose / -v, --output / -o, --help / -h.
Convention 2: Standard Flags Everyone Expects
Certain flags are so universal that omitting them is a bug:
--help/-h: Print usage information and exit with code0.--version/-V: Print the tool's version and exit with code0.--verbose/-v: Increase output detail. Some tools support-vvvfor progressively more detail.--dry-run/-n: Show what would happen without actually doing it. Essential for destructive operations.--quiet/-q: Suppress all non-error output. Essential for use in scripts.
Convention 3: The Double Dash Separator (--)
This is a critical safety and robustness standard that many engineers don't know about until they encounter a bug caused by its absence.
The -- signals to the argument parser: "Stop interpreting flags after this point. Everything that follows is a literal positional argument."
Consider a tool that deletes files: deleter <filename>. Normally, deleter myfile.txt works fine. But what if a file was created with a name that starts with a dash — for example, a file literally named -rf? (This can happen through buggy scripts or malicious input.)
If you run deleter -rf, your tool's parser sees -r and -f as flags, not as a filename. The behavior is undefined or dangerous.
The fix is the double dash: deleter -- -rf. The parser sees --, stops looking for flags, and treats -rf as the first positional argument — the filename you actually want to delete.
Your tools must support this convention to handle arbitrary inputs safely. Argument parsing libraries support it automatically; you just need to know it exists and test for it.
Interviewers sometimes ask: "How would you make a CLI tool safe to use with untrusted or user-provided input?" The double dash convention is a key answer. Explain that any input starting with a dash could be misinterpreted as a flag, and that the -- separator is the POSIX-standard way to prevent this. Pair this with input validation and you have a complete answer.