Опыт создания сценариев UNIX

Несмотря на то что фрагменты программ снабжены некоторыми комментариями и сообщениями о правильном применении сценариев (поскольку мы хотели обратить ваше внимание на кое-какие нюансы), хотелось бы, чтобы реальные сценарии были еще лучше. Существует множество книг о написании качественных программ, но все же будет не лишним изложить здесь некоторые основные рекомендации по написанию сценариев.

  • При запуске с неадекватными аргументами сценарий должен вывести сообщение о его корректном применении и завершиться. Можно также реализовать возможность получения справочной информации (—help).
  • Проверяйте входные данные и выходные значения на корректность. Прежде чем выполнять команду rm -rf (удаление указанных имен файлов из каталога), хорошо было бы, чтобы сценарий сначала удостоверился, что полученный в результате путь будет соответствовать ожидаемому образцу. Такие двойные предосторожности (и средства языка, которые позволяют их реализовать) иногда оказываются весьма полезными.
  • Сценарий должен возвращать надлежащий код завершения: нуль — в случае успешного выполнения и ненулевое значение — при неудачном исходе. Необязательно сопровождать каждый вид отказа уникальным кодом завершения, однако следует поинтересоваться, какая информация была бы полезной для вызывающих процедур.
  • Используйте соответствующие соглашения о присвоении имен для переменных, сценариев и подпрограмм. Приведите в соответствие соглашения, действующие в языке, в остальной части кодовой основы вашего, что самое важное, других переменных и функциях, определенных в текущем проекте. Используйте принцип смешанного регистра букв или знаки подчеркивания, чтобы сделать читабельными длинные имена.13
  • Для переменных используйте имена, которые отражают хранимые в них значения, но старайтесь все же давать имена покороче. Например, переменную для хранения количества входных строк можно, конечно, назвать numberoflinesofinput, но уж очень оно длинное, и его лучше заменить так: nlines.
  • Разработайте руководство по стилю, чтобы вы и ваши коллеги могли писать код, используя одни и те же соглашения. Такое руководство облегчит вам понимание кода, написанного другими программистами, а им — написанного вами.
  • Начинайте каждый сценарий с блока комментария, в котором будет сказано, что делает данный сценарий и какие параметры он принимает. Не забудьте указать свое имя и текущую дату. Если сценарий требует, чтобы в системе были инсталлированы нестандартные инструменты, библиотеки или модули, обязательно перечислите их.
  • Комментируйте свой код, используя такую степень детализации, какую посчитаете полезной, с учетом временного "отхода" от этого кода и с последующим возвратом к нему через месяц или два. Имеет смысл также комментировать выбор алгоритма, причины неиспользования более очевидного способа кодирования, необычные пути в коде, все "трудные места", возникшие в период разработки. Не загромождайте код бесполезными комментариями; отнеситесь к написанию комментариев с точки зрения потенциального читателя: пишите лаконично, грамотно и "по делу".
  • Комментарии кода лучше всего применять к целым блокам или функциям. Комментарии, которые описывают назначение переменной, следует вставлять вместе с объявлением этой переменной или при ее первом использовании.
  • Лучше запускать сценарии от имени суперпользователя root. Не устанавливайте для них атрибут setuid, поскольку такие сценарии довольно трудно сделать совершенно безопасными. Для того чтобы реализовать надлежащие стратегии управления контролем доступа, используйте команду sudo.
  • В оболочке bash используйте ключ -х, чтобы отобразить команды, прежде чем они будут выполнены, и ключ — n, чтобы проверить синтаксис команд без их выполнения.
  • Используйте Perl-ключ -w, который предупредит вас о подозрительном поведении, например об использовании переменных до установки их значений. Вы можете использовать этот ключ в "описательной" строке или "внедрить" его в текст программы с помощью директивы use  warnings.
  • Выполняя Python-сценарий, вы находитесь в режиме отладки, если явно не отключите его с помощью аргумента — 0 в командной строке. Это означает, что еще до вывода диагностических выходных данных вы можете протестировать специальную переменную        debug__.
  • Том Кристиансен (Tom Christiansen) предлагает следующие пять золотых правил для генерирования полезных сообщений об ошибках.
  • Сообщения об ошибках должны направляться в канал STDERR, а не STDOUT.
  • Включайте в сообщение об ошибке имя программы.
  • Указывайте виновника (имя функции или операции) ошибочного действия.
  • Если к сбою приводит системный вызов, включите строку perror ($! в языке Perl).
  • Если код завершения некоторой операции не равен нулю, обеспечьте выход из программы.

 

В среде Perl несложно следовать всем этим пяти правилам.

die "can't open $filename:  $!";

 

Комментарии (0)

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.