Posts on this page:
Сегодня хочу поговорить про использование алиасов в скриптах и дать несколько практических советов при сборке текстов из фрагментов.
Семантика языка PowerShell подразумевает использование унифицированного синтаксиса, где название каждой команды явно говорит о том, что она делает. Например, Get-Process. Совершенно очевидно, что эта команда должна делать. Но, порой, эти команды бывают очень длинными и набирать их постоянно в консоли бывает не очень удобно. Например, самый топовый — Get-ChildItem. Это даже не самая длинная команда, просто наиболее часто используемая. Или Foreach-Object. Даже автозавершение команд не всегда спасает ситуацию. Для этого были придуманы алиасы (короткие ссылки на команды), которые очень выгодно использовать в консоли. Так же у команд есть и очень длинные параметры. Например, всякие –InputObject, –Include, –ErrorAction и т.д. PowerShell позволяет сокращать параметры первыми буквами до тех пор, пока эти буквы не будут явно указывать на конкретное название. Например, у команды Get-ChildItem параметр –Include может быть сокращён до –I, а –Exclude до –Ex. Но многие скриптописатели пишут скрипты (и выкладывают их даже где-то) с использованием этих самых алиасов и коротких обозначений параметров.
Наконец-то я смог выкроить время на то, чтобы написать что-нибудь ещё полезного в бложек. В последнее время я занимался весьма интересными вопросами, результатами которых я, может, как-нибудь поделюсь здесь. А может быть и не поделюсь :-)
Сегодня я постараюсь продолжить тему гайдлайнов PowerShell. Сегодня хочу поговорить о форматировании кода и проблемах именования переменных.
Неотформатированный код можно смело кидать в ресуклер, даже не вникая в него. Можете соглашаться, а можете и нет, но суть от этого не меняется. В принципе, PowerShell не имеет своих стандартов форматирования кода, но их можно унаследовать из IDE, как Visual Stidio. В основном это относится к разбивке сложных выражений на несколько строк и отступе от левого края. Разбивка сложных выражений проводится по таким символам, как: круглая скобка — (, квадратная скобка — [ (хотя, чаще она используется как метасимвол регулярных выражений) или фигурная скобка — {. Любые открывющиеся скобки в PowerShell являются признаком начала какой-то вложенной конструкции. И эти конструкции, если они достаточно длинные, следует располагать на новой строке. Открывающаяся скобка должна быть последним символом в текущей строке (или быть единственным символом в строке), а закрывающая скобка должна быть на отдельной строке. При этом весь код внутри конструкции должен быть отбит дополнительным табом от основного кода (т.е. не быть на одном уровне).
Любой хорошо написанный скрипт должен содержать справочную информацию о себе. Справочная информация должна содержать как минимум:
Я видел множество вариантов оформления справки. Самые популярные это:
Я не буду останавливаться на том, как это всё выглядит, а лишь расскажу, как должна быть оформлена справка к команде. Windows PowerShell предлагает нам 2 пути.
Продолжаю начатую в прошлый раз цикл постов про гæдлайны оформления скриптов в PowerShell или «учимся писать скрипты». Сегодня мы поговорим о таких вещах, как оформление скриптов, правила именования скриптов/функций и поговорим о типах скриптов и функций — простых и расширенных (advanced).
Правильно написанный скрипт, который даже в теории может быть использован кем-то другим (или прочитан), должен содержать шапку. В шапке указывается название скрипта, краткое описание его работы (функций), версия скрипта, дата последнего изменения, автор скрипта и какие-то контактные данные, если потребуется связаться с автором кода. Вот примерный шаблон этой самой шапки:
Мы с Васей Гусевым задумали утопичную идею составить какой-то набор гæдлайнов как правильно писать скрипты для PowerShell. Так исторически сложилось, что каждый пишет скрипты так, как он хочет/удобней/умеет. PowerShell один из самых новых языков скриптования (в отличии от vbs/cmd) и он внёс совершенно новый синтаксис и идею оформления кода, который как правило несовместим с жизнью с другими языками.
Я повидал множество скриптов, написанных разными пользователями и на основании их мы будем стараться разбирать наиболее частые ошибки в оформлении кода и прививать людям какие-то общие правила, как надо писать скрипты. Это связано с тем, что подавляющее количество ваших скриптов будет читаться кем-то ещё (например, вашим коллегой, боссом, etc.). И правильно оформленные скрипты упрощают и ускоряют его чтение и понимание.