I’ve developed a pet peeve over time as I’ve seen others show their command line usage of jdupes in issue reports and examples. I’m sick of seeing long options.
The only way in which long options are good is that they are self-documenting. If you see --recurse then you have a pretty good idea what the option does while a simple -r doesn’t tell you anything meaningful. This is helpful to people who have no clue what’s going on or what they’re doing because they don’t need to look up anything. That’s where the value ends.
The case against long options
Rather than subject you to a wordy rant, here’s a concise list of why long options shouldn’t be used for almost everyone that’s not a total newbie:
- Too much unnecessary typing.
jdupes -rLHZQO1y .takes a lot less time to type thanjdupes --recurse --link-hard --hard-links --soft-abort --quick --param-order --one-file-system --hash-db=. - They’re not actually self-documenting. What’s the difference between
--link-hardand--hard-linksin the previous command? The only way to know is to read the help text, but that’s the same thing you’d do to learn what the single-character options do. - The apparent self-documenting nature is deceptive. It can lead people to not read the help text and understand what things actually do.
-Q/--quickis a speed tradeoff has a small but serious risk of data loss. One check of the help text to find out what-Qmeans will reveal this, but--quickimplies faster, so why check? - Higher verbosity is more difficult to work within. Imagine working with the short and long examples above. If you know what a character option does, you can mentally parse the intent of
-rLHZQ1Oy .very quickly, but the long option counterpart takes more time to scan and absorb. Editing a command line full of long options is tedious, especially if you don’t know that CTRL+left/right skips entire words at a time. It is also mentally very easy to swap “hard links” and “link hard” since they are nearly identical and cognitive swap errors are not uncommon. - Having both short and long options can double cognitive load. I need to deal with scripts or issue reports and they could use long options instead of short options. Now I have two separate things to memorize instead of one. I actually had to look up several long options for the above examples because I never use them.
I don’t think that long options should completely go away. They have their place, especially if a complex program starts to exhaust the limited set of single-character options available; in fact, this is an issue which jdupes is already brushing up against, with several options getting random characters because there are only two ways to write the letter R or L or S. I think long options are a niche tool that shouldn’t be used for most purposes. hdparm notoriously uses --please-destroy-my-drive as gatekeeping for options with very dangerous consequences and I think that’s fine, but when someone’s using my duplicate scanner tool to find duplicates including hard links and delete them, I’m always going to get a little angry inside when I see
--recurse --hard-links --delete --no-promptinstead of
-rHdN