When working on the command line, it’s perfectly fine to use short-format flags. For example:
$ ls -al
This is memorable, easy to type, and helps you focus on accomplishing the task at hand.
However, when writing shell scripts that will be used over and over, it’s tempting to write in the same, comfortable short-flag style. However, compare the following:
#!/bin/bash # Short-flag style ls -al # Long-flag style ls --all -l
We still have a short style flag in the second version of ls, but that’s because there’s no long version of the -l (long listing format) flag. There is, however, a long version of the -a (all) flag that makes it much clearer what’s going on. And this leads us to an important principle in writing good software:
Optimize for read time productivity, not write-time productivity.(See Code Complete by Steve McConnell)
Ideally, software will only ever be written once (and possibly changed a few times). However, it will be read over and over, by multiple people from a myriad of backgrounds over an indeterminate period of time. Thus, make these people your target audience. Don’t make them work harder than absolutely necessary to understand your code.
At the end of the day, programming is communication: with the computer, with other programmers, and ultimately with end users. Strive for clear communication every step of the way.
It takes a bit more time and effort up front, but, where possible, using long-format flags in shell scripts is an easy way to improve communication with your fellow developers and hopefully improve the quality of the code you write.