Five key points are to follow when writing a maintainable shell script: 1. Declare the interpreter at the beginning and enable the set option to improve robustness; 2. Use meaningful variables and function names to enhance readability; 3. Add comments reasonably and use getopts to process parameters to improve usability; 4. Separate configuration and logic to facilitate adjustment; 5. Modular functions improve reusability and structural clarity. Each shell script should start with #!/bin/bash or #!/bin/sh, and discover problems early through set -e, set -u and set -o pipefail; avoid fuzzy variable names such as a when naming, and it is recommended to use log_file to express the intent name; functions such as backup_config() can improve the degree of code modularity; it is recommended to place functions uniformly for management; use getopts for parsing rather than directly accessing positional parameters for scripts with parameters; in order to improve maintainability, tunable parameters such as MAX_RETRIES and TIMEOUT should be centrally defined in the top or external files; through these best practices, even if the script functions are simple, it can significantly reduce the difficulty of later maintenance.

The key to writing a maintainable shell script is to have clear structure, simple logic, and standardized naming. Many people start by writing a small script to complete a task, but as the requirements change, the script becomes more and more complex and eventually becomes difficult to maintain. To avoid this, paying attention to some best practices from the beginning will save a lot of trouble.

Use interpreter declaration and set options

Each shell script should start with #!/bin/bash or #!/bin/sh and be specified based on the actual shell used. This is not only to enable the script to run directly, but also to clarify the execution environment.

In addition, adding the following statement can help you find problems earlier when something goes wrong:

 set -e # Exit immediately when an error occurs -u # An error is reported when referring to an undefined variable set -o pipefail # Any command in the pipeline fails and is marked as failure

These settings prevent the script from continuing to execute in partial failures, thus hiding the problem.

Give variables and functions meaningful names

Although shell scripts are short, they should also pay attention to readability. For example:

• ? Not recommended: a="some path"
• ? Recommended: log_file="/var/log/app.log"

Function names should also express the intention clearly, such as:

 backup_config() {
    cp "$1" "$1.bak"
}

Compared to a bunch of exposed commands piled together, functions can modularize the code and improve reusability and readability.

If there are multiple functions in the script, it is recommended to place them at the beginning of the file or in a separate lib file for easy search and management.

Use comments and parameter processing rationally

Shell scripts are easily turned into "one-time" things, but if they are used by others, or you will come back and modify them in a few months, don't miss the comments. Especially in functional descriptions, parameter meanings, important logical branches, etc.

For scripts with parameters, try to use getopts to parse command line parameters instead of directly accessing $1 and $2 . This makes it clearer and easier to expand.

Let's give a simple example:

 while getopts "f:n:" opt; do
  case $opt in
    f) filename="$OPTARG" ;;
    n) count="$OPTARG" ;;
    *) echo "Usage: $0 -f <file> -n <count>"; exit 1 ;;
  esac
done

In this way, users can flexibly pass parameters when calling scripts, such as script.sh -f input.txt -n 5 .

Separate configuration and logic for easy adjustment

If your script needs to frequently modify parameters such as path, timeout, retry count, etc., you can put them in a configuration area, such as defining variables at the top:

 MAX_RETRIES=3
TIMEOUT=10
DATA_DIR="/data/output"

In this way, others can find the adjustable parts at a glance when reading the script, without having to go deep into the logic and guess where to change it.

In addition, you can also consider extracting the configuration into an external file and introducing it through source config.sh to further improve flexibility.

Basically that's it. Writing shell scripts does not have to be very advanced, but as long as the structure is clear, the logic is clear, and the variable naming is reasonable, it will be much easier to maintain in the later stage.

The above is the detailed content of What are best practices for writing maintainable shell scripts?. For more information, please follow other related articles on the PHP Chinese website!