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

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

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

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

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

Итак, я обещал привести несколько примеров псевдонимов PowerShell. Некоторые из псевдонимов, с которыми вы можете иногда столкнуться, включают IPMO, GWMI. Вы знаете, что делают эти команды? Если нет, то вы, вероятно, поняли мою мысль. Псевдонимы могут затруднить чтение кода PowerShell. Псевдоним IPMO — это аббревиатура командлета Import-Module. Точно так же псевдоним GWMI является сокращением от Get-WMIObject. Дело в том, что ваш код будет намного проще понять другим людям, если вы избегаете использования псевдонимов.

Я упомянул, что было большое исключение из правил. В некоторых версиях PowerShell Where-Object можно сократить до Where. На мой взгляд, Where легче читать, чем Where-Object, тем более, что Where широко используется в некоторых других языках программирования. Кстати, командлет Where-Object тоже можно заменить знаком вопроса. Однако я рекомендую этого не делать, потому что, если кто-то не знает, что вопросительный знак означает «Где-объект», ему придется пытаться выяснить, что именно делает код.

Так что насчет тех серых зон, о которых я упомянул? Ну, я должен признать, что я немного сомневаюсь, когда дело доходит до определенных псевдонимов. Есть несколько псевдонимов, которые настолько широко используются, что большинство людей, имеющих базовое представление о PowerShell, вероятно, узнают их. Тем не менее, эти конкретные псевдонимы не совсем интуитивно понятны и могут быть немного загадочными для тех, у кого нет опыта работы с PowerShell. Я говорю о таких псевдонимах, как FT (Format-Table) и FL (Format-List). На мой взгляд, лучше всего будет написать полные командлеты, но, вероятно, это не вызовет серьезных проблем, если вы решите этого не делать.

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

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

Когда я пишу сценарий PowerShell, мне нравится вставлять несколько пустых строк между основными функциональными областями сценария. Да, я использую пустые строки для отделения функций друг от друга и от тела скрипта, но иногда я также использую пустые строки внутри тела скрипта.

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

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

Использование заглавных букв также может облегчить чтение сценария. Microsoft обычно рекомендует при вводе командлета PowerShell (или параметра) использовать первую букву каждого слова с заглавной буквы. Например, вы можете ввести ForEach-Object, а не foreach-object. Вставка заглавных букв в начале каждого слова упрощает чтение глаголов и существительных, составляющих командлет. Это не имеет большого значения для коротких командлетов, но некоторые командлеты используют несколько слов.

Есть одна область, в которой я склонен идти против лучших практик Microsoft. Мне нравится писать аббревиатуры в командлетах PowerShell с заглавной буквы, потому что я думаю, что это облегчает чтение командлета. Например, я мог бы использовать Get-WMIObject вместо Get-WmiObject. Это просто личное предпочтение, и можно использовать либо весь акроним, либо только первую букву.

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

Вывод

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

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