32.1. Неофициальные рекомендации по оформлению сценариев

• Комментируйте свой код. Это сделает ваши сценарии понятнее для других, и более простыми, в обслуживании, для вас.

  PASS="$PASS${MATRIX:$(($RANDOM%${#MATRIX})):1}"
  # Эта строка имела некоторый смысл в момент написания,
  # но через год-другой будет очень тяжело вспомнить -- что она делает.
  # (Из сценария "pw.sh", автор: Antek Sawicki)
  

  
  
  

  Добавляйте заголовочные комментарии в начале сценария и перед функциями.

  #!/bin/bash
  
  #************************************************#
  #                   xyz.sh                       #
  #             автор: Bozo Bozeman                #
  #                Июль 05, 2001                   #
  #                                                #
  #          Удаление файлов проекта.              #
  #************************************************#
  
  BADDIR=65                       # Нет такого каталога.
  projectdir=/home/bozo/projects  # Каталог проекта.
  
  # ------------------------------------------------------- #
  # cleanup_pfiles ()                                       #
  # Удаляет все файлы в заданном каталоге.                  #
  # Параметры: $target_directory                            #
  # Возвращаемое значение: 0 -- в случае успеха,            #
  #                        $BADDIR -- в случае ошибки.      #
  # ------------------------------------------------------- #
  cleanup_pfiles ()
  {
    if [ ! -d "$1" ]  # Проверка существования заданного каталога.
    then
      echo "$1 -- не является каталогом."
      return $BADDIR
    fi
  
    rm -f "$1"/*
    return 0   # Успешное завершение функции.
  }
  
  cleanup_pfiles $projectdir
  
  exit 0
  

  Не забывайте начинать ваш сценарий с sha-bang -- #!/bin/bash.
  
  

• Заменяйте повторяющиеся значения константами. Это сделает ваш сценарий более простым для понимания и позволит вносить изменения, не опасаясь за его работоспособность.

  if [ -f /var/log/messages ]
  then
    ...
  fi
  # Представьте себе, что через пару лет
  # вы захотите изменить /var/log/messages на /var/log/syslog.
  # Тогда вам придется отыскать все строки,
  # содержащие /var/log/messages, и заменить их на /var/log/syslog.
  # И проверить несколько раз -- не пропустили ли что-нибудь.
  
  # Использование "констант" дает лучший способ:
  LOGFILE=/var/log/messages  # Если и придется изменить, то только в этой строке.
  if [ -f "$LOGFILE" ]
  then
    ...
  fi
  

  
  
  

• В качестве имен переменных и функций выбирайте осмысленные названия.

  fl=`ls -al $dirname`                 # Не очень удачное имя переменной.
  file_listing=`ls -al $dirname`       # Уже лучше.
  
  
  MAXVAL=10   # Пишите имена констант в верхнем регистре.
  while [ "$index" -le "$MAXVAL" ]
  ...
  
  
  E_NOTFOUND=75                        # Имена кодов ошибок -- в верхнем регистре,
                                       # к тому же, их желательно дополнять префиксом "E_".
  if [ ! -e "$filename" ]
  then
    echo "Файл $filename не найден."
    exit $E_NOTFOUND
  fi
  
  
  MAIL_DIRECTORY=/var/spool/mail/bozo  # Имена переменных окружения
                                       # так же желательно записывать символами
                                       # в верхнем регистре.
  export MAIL_DIRECTORY
  
  
  GetAnswer ()                         # Смешивание символов верхнего и нижнего решистров
                                       # удобно использовать для имен функций.
  {
    prompt=$1
    echo -n $prompt
    read answer
    return $answer
  }
  
  GetAnswer "Ваше любимое число? "
  favorite_number=$?
  echo $favorite_number
  
  
  _uservariable=23                     # Допустимо, но не рекомендуется.
  # Желательно, чтобы пользовательские переменные не начинались с символа подчеркивания.
  # Так обычно начинаются системные переменные.
  

  
  
  

• Используйте смысловые имена для кодов завершения.

  E_WRONG_ARGS=65
  ...
  ...
  exit $E_WRONG_ARGS
  

  См. так же Приложение D.
  
  

• Разделяйте большие сложные сценарии на серию более коротких и простых модулей. Пользуйтесь функциями. См. Пример 34-4.

• Не пользуйтесь сложными конструкциями, если их можно заменить простыми.

  COMMAND
  if [ $? -eq 0 ]
  ...
  # Избыточно и неинтуитивно.
  
  if COMMAND
  ...
  # Более понятно и коротко.
  

  
  
  

	... читая исходные тексты сценариев на Bourne shell (/bin/sh). Я был потрясен тем, насколько непонятно и загадочно могут выглядеть очень простые алгоритмы из-за неправильного оформления кода. Я не раз спрашивал себя: "Неужели кто-то может гордиться таким кодом?"
	Landon Noll