32.1. Неофициальные рекомендации по оформлению сценариев
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
См. так же Приложение C.
? Разделяйте большие сложные сценарии на серию более коротких и простых модулей. Пользуйтесь функциями. См. Пример 34-4.
? Не пользуйтесь сложными конструкциями, если их можно заменить простыми.
? COMMAND
? if [ $? -eq 0 ]
? ...
? # Избыточно и неинтуитивно.
?
? if COMMAND
? ...
? # Более понятно и коротко.
... читая исходные тексты сценариев на Bourne shell (/bin/sh). Я был потрясен тем, насколько непонятно и загадочно могут выглядеть очень простые алгоритмы из-за неправильного оформления кода. Я не раз спрашивал себя: "Неужели кто-то может гордиться таким кодом?"
Landon Noll