Should Bash Functions Use Positional Arguments or Named Options?

A few implementation details are worth considering too. You do not need the `function` keyword in Bash function declarations, although using it consistently is valid in Bash. For option parsing, look at `getopts` first if short options are enough; it is built into Bash. If you need long options, use a carefully written parser or an appropriate `getopt` implementation.

Whatever style you choose, consistency with similar commands matters more than following a rigid rule. Keep required input obvious, give optional settings defaults, and avoid making callers pass empty strings just to reach a later argument.

You could also make some values configurable through variables or the environment. For example, a default vault user or debug setting could be established once and overridden by an option when necessary. That can reduce repetitive parameter passing, although it should be documented clearly because environment-based configuration is less visible at the call site.

Also, the function interface could avoid requiring a debug value at all: make debug off by default and enable it with `--debug`. For the vault user, either omit the option when it is not needed or provide an explicit option such as `--vault-user name`.

A useful starting rule is that positional arguments represent data, while options control behavior or configure how the command runs. The parameter name is a good positional argument because it is the main piece of data. Debugging and the optional vault user are better represented as options, especially once there are several of them.

For example, an interface like `run_aws_ssm_get_parameter --parameter-name some_param --debug --vault-user name` is easier to read than relying on empty placeholders and fixed positions. Bash’s `getopts` can handle short options, and `getopt` or a small manual parser can handle longer options. Boolean settings are usually clearer as `--debug` and optionally `--no-debug`, rather than requiring the caller to write `true` or `false`.

There is no universal rule, but required values generally work well as positional arguments and optional settings work well as flags or options. Optional positional arguments should normally come after required ones so callers can omit them without inserting placeholders.

For functions called only by other shell code, a few fixed positional arguments can be perfectly reasonable. For commands intended for humans, named options and sensible defaults make the interface more self-documenting. Once a function has more than a few arguments, positional ordering becomes brittle and option parsing is usually worth adding.