Согласованность Microsoft в именовании параметров PowerShell CmdLet

Допустим, я написал сценарий PowerShell, который включает в себя эту команду:

Get-ChildItem -Recurse

Но вместо этого я написал:

Get-ChildItem -Re

Экономить время. По прошествии некоторого времени, когда я обновил свою версию PowerShell, Microsoft решила добавить в Get-ChildItem параметр с именем «-Return», который, например, возвращает True или False в зависимости от того, найдены какие-либо элементы или нет.

Должен ли я в этом виртуальном сценарии редактировать все свои прежние сценарии, чтобы гарантировать, что сценарий будет функционировать должным образом? Я понимаю попытку Microsoft сэкономить мое время набора текста, но это моя забота, и поэтому я, вероятно, всегда буду стараться писать полное имя параметра.

Если, конечно, вы не знаете чего-то, чего не знаю я. Спасибо за ваше понимание!


parameters powershell consistency naming convention
person Arto Kalishian    schedule 31.12.2016    source источник

Ответы (1)


arrow_upward
11
arrow_downward

Это больше похоже на разглагольствование, чем на вопрос, но ответ:

Должен ли я в этом виртуальном сценарии редактировать все свои прежние сценарии, чтобы гарантировать, что сценарий будет функционировать должным образом?

Да!

Вы должны всегда использовать полные имена параметров в сценариях (или любом другом фрагменте повторно используемого кода).

Автоматическое разрешение частичных имен параметров, псевдонимов и других сокращений очень удобно при интерактивном использовании PowerShell. Это позволяет нам запустить powershell.exe и сделать:

ls -re *.ps1|% FullName

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

Но если бы мне нужно было включить эту функциональность в скрипт, я бы сделал:

Get-ChildItem -Path $Home -Filter *.ps1 -Recurse |Select-Object -ExpandProperty FullName

не только по причинам, которые вы упомянули, но также для последовательности и удобочитаемости - если мой коллега придет и, возможно, не знаком с ярлыками, которые я использую, он все равно сможет различить значение и ожидаемый результат от трубопровод.

Примечание. В настоящее время существует три открыть проблемы на GitHub, чтобы добавить правила предупреждения об этом в PSScriptAnalyzer. Я уверен, что сопровождающие проекта люблю руку с этим :-)

person Mathias R. Jessen    schedule 31.12.2016
comment
Спасибо за Ваш ответ. Это не разглагольствования, но я читал популярную книгу «Изучите Windows PowerShell за месяц», и автор не указал это требование в сценариях. Он просто сказал, что вы можете написать короткий параметр и т. д. Поэтому я подумал, что важно спросить, есть ли у Microsoft что-нибудь сказать по этому поводу, о чем я не слышал. В любом случае, то, что вы сказали, имеет большой смысл. Большое спасибо. - person Arto Kalishian; 31.12.2016
comment
Я не могу найти никаких официальных ссылок, но все соответствующие сотрудники Microsoft и MVP, с которыми я обсуждал эту тему, соглашаются, не моргая. - person Mathias R. Jessen; 31.12.2016
comment
Редактировать: автор книги, на которую я ссылался, упомянул всегда указывать полный параметр при написании скриптов далее в этой главе. Я просто хотел исправить эту информацию, чтобы отдать ему должное. - person Arto Kalishian; 31.12.2016
comment
Почему вы заменяете % FullName на Select-Object -ExpandProperty FullName, а не на этот ForEach-Object FullName? - person user4003407; 31.12.2016
comment
@PetSerAl обратная совместимость - person Mathias R. Jessen; 31.12.2016
comment
@ArtoKalishian Пожалуйста, примите мой ответ (щелкнув галочку слева), если он решит вашу проблему / ответит на ваш вопрос - person Mathias R. Jessen; 31.12.2016
comment
Конечно, и извините за задержку, потому что я новичок во всех этих вещах с переполнением стека. Я даже не мог проголосовать за вас, потому что мне еще не разрешено :) - person Arto Kalishian; 01.01.2017
comment
К сожалению, я не могу найти кнопку. Кажется, у меня до сих пор нет этой опции. - person Arto Kalishian; 01.01.2017