Рекомендации по написанию сценариев PowerShell (часть 2)

• Рекомендации по написанию сценариев PowerShell (часть 3)
• Рекомендации по написанию сценариев PowerShell (часть 4)
• Рекомендации по написанию сценариев PowerShell (часть 5)
• Рекомендации по написанию сценариев PowerShell (часть 6)

В первой статье этой серии я говорил о необходимости добавления комментариев к сценариям PowerShell и о том, как важно не переборщить с комментариями. В самом конце этой статьи я кратко упомянул, что хороший сценарий PowerShell должен быть самодокументируемым, но я не стал вдаваться в подробности относительно того, что имел в виду под этим. В таком случае я хочу уделить немного времени разговору о самодокументированных сценариях.

Большинство рекомендаций по созданию самодокументируемых сценариев относятся к использованию переменных и функций. PowerShell действительно гибок, когда речь заходит о переменных, которые вы можете использовать. Вы не можете использовать пробелы (или некоторые другие специальные символы) в именах переменных, и вы не можете использовать некоторые зарезервированные слова, но помимо этих ограничений PowerShell позволит вам делать все, что вы хотите по большей части. Я рекомендую воспользоваться этой гибкостью и использовать действительно осмысленные имена переменных.

Я буду первым, кто признает, что от старых привычек трудно избавиться и что переход к использованию действительно хороших имен переменных может оказаться трудным. Я был ребенком 80-х и рос, я проводил бесчисленные часы за написанием программ на своем цветном компьютере Radio Shack (или CoCo, как он был более известен). Как и многие другие системы того времени, CoCo была разработана для программирования на BASIC и была чрезвычайно ограничена, когда дело касалось использования переменных. Переменные должны были состоять из одного или двух символов, и если переменная использовалась для хранения текста, то за именем переменной должен был следовать знак доллара. Конечным результатом было то, что многие подпрограммы, которые я тогда написал, включали объявления переменных, очень похожие на алгебраические уравнения. Чтобы показать вам, что я имею в виду, вот несколько примеров того, как тогда выглядело назначение переменных:

Х=2*У
N$ = «Брайен»

В начале 90-х я перешел от программирования на BASIC к программированию на других языках, таких как C++ и Pascal. При этом я обнаружил, что компиляторы, которые я использовал, не были такими строгими в отношении имен переменных. Как и в PowerShell, переменные могут состоять из имен, а не из одной или двух букв.

Сначала я был совершенно против использования этих типов имен переменных. В конце концов, я вырос, используя одно- и двухсимвольные имена переменных, и эти имена стилей все еще работали, поэтому я не видел необходимости переключаться. Эта идея была дополнительно подкреплена некоторыми из моих предыдущих попыток использовать описательные имена переменных. Я обнаружил, что при этом мне приходится больше печатать, а отладка становится немного сложнее, потому что существует большая вероятность сделать опечатку при ссылке на переменную. Кроме того, некоторые из компиляторов, которые я использовал в 90-х годах, были чувствительны к регистру.

Однако по мере того, как я набирался опыта программиста, я начал понимать важность использования осмысленных имен переменных. Особенно это касалось более длинных программ.

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

Формула, которую НАСА использует для расчета подъемной силы крыла:

L = CI * ((P*V ² )/2)*A

Очевидно, что эту формулу можно без проблем ввести в скрипт как есть. Однако даже в этом случае человеку, не имеющему опыта работы в аэрокосмической отрасли, было бы трудно расшифровать эту формулу. Подумайте об этом на мгновение. Что мы рассчитываем? Что означают переменные?

Все становится намного более интуитивным, когда используются осмысленные имена переменных. Приведенную выше формулу можно было бы лучше выразить так:

Подъемная сила = Коэффициент * ((Плотность * Скорость ² )/2 * Площадь крыла

Как видите, формулу становится намного легче понять, когда используются осмысленные имена переменных. Однако недостаточно использовать только осмысленные имена переменных.

Еще один лучший способ написания сложных сценариев PowerShell — объявить все ваши переменные в верхней части сценария. Это значительно упрощает определение заранее, какие переменные будут использоваться в скрипте и для чего эти переменные будут использоваться. Кстати, я настоятельно рекомендую использовать комментарии, чтобы объяснить, для чего используется каждая переменная.

Говоря о переменных, я также рекомендую настроить сценарии PowerShell для использования строгого режима. Я буду первым, кто признает, что использование строгого режима может вызывать разочарование, если вы не придерживаетесь установленных передовых практик PowerShell. В конце концов, работа строгого режима заключается в том, чтобы вызвать сообщение об ошибке, если ваш сценарий отклоняется от лучших практик. Однако со временем использование строгого режима сделает вас лучшим программистом.

Строгий режим запускается с помощью командлета PowerShell с именем Set-StrictMode. Я не буду вдаваться во все особенности использования этого командлета, но вы можете найти синтаксис здесь.

Что я действительно хочу объяснить, так это то, что когда вы реализуете строгий режим для текущей области (и дочерних областей), это приведет к тому, что PowerShell выдаст завершающую ошибку, если вы используете плохо написанное выражение, сценарий или блок сценария. Когда строгий режим отключен (что является обычным поведением PowerShell), неинициированные переменные обрабатываются так, как если бы они имели значение либо 0, либо $null. Если ваш скрипт попытается сослаться на несуществующее свойство, это тоже вернет значение $null.

Поведение строгого режима зависит от версии строгого режима, на которую вы ссылаетесь в своем сценарии. Например, и версия 1.0, и версия 2.0 предотвращают использование неинициированных переменных (версия 2 делает и другие вещи).

Хотите верьте, хотите нет, но в использовании строгого режима есть преимущество, помимо простого соблюдения лучших практик. Если предполагается, что необъявленная переменная содержит значение 0, вы можете получить некоторые неверные вычисления в результате простой опечатки. Позвольте мне показать вам, что я имею в виду.

Предположим на мгновение, что у нас есть переменная с именем $X, и мы хотим установить ее равной 6. Теперь предположим, что мы хотим проверить, больше ли $X 5, но мы случайно дважды нажали клавишу X и укажите переменную как $XX. Посмотрите на рисунок А, на котором показано, что произойдет:

Рисунок A: PowerShell возвращает неправильный результат, потому что я случайно ввел неправильное имя переменной.

Как вы можете видеть на рисунке, PowerShell вернул результат False, хотя результат «должен был быть» истинным. Это происходит потому, что я неправильно набрал имя переменной. Если бы это был сложный сценарий, то эта опечатка одного символа могла бы иметь волновой эффект, который приводит к серьезной ошибке.

И наоборот, взгляните на то, что происходит на рисунке B, когда я делаю точно такую же опечатку, но с включенным строгим режимом. В этом случае PowerShell говорит мне, что я сделал что-то не так, а не просто неправильно выполнил расчет.

Рисунок B. Строгий режим помогает обнаруживать ошибки до того, как они станут серьезной проблемой.

Вывод

Использование переменных играет огромную роль в рекомендациях по написанию сценариев PowerShell. В части 3 я продолжу обсуждение, поделившись с вами лучшими практиками.

• Рекомендации по написанию сценариев PowerShell (часть 3)
• Рекомендации по написанию сценариев PowerShell (часть 4)
• Рекомендации по написанию сценариев PowerShell (часть 5)
• Рекомендации по написанию сценариев PowerShell (часть 6)