Книга: Искусство программирования на языке сценариев командной оболочки

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

Оглавление книги