【问题标题】：Microsoft's Consistency in PowerShell CmdLet Parameter Naming微软在 PowerShell CmdLet 参数命名方面的一致性
【发布时间】：2016-12-31 11:02:01
【问题描述】：

假设我编写了一个包含此命令的 PowerShell 脚本：

Get-ChildItem -Recurse

但我写的是：

Get-ChildItem -Re

为了节省时间。经过一段时间后，我升级了我的 PowerShell 版本，Microsoft 决定向 Get-ChildItem 添加一个名为“-Return”的参数，例如，根据是否找到任何项目返回 True 或 False。

在那个虚拟场景中，我是否需要编辑所有以前的脚本以确保脚本能够按预期运行？我理解 Microsoft 试图节省我的打字时间，但这是我的担心，因此我可能会一直尝试编写完整的参数名称。

当然，除非你知道一些我不知道的事情。感谢您的洞察力！

【问题讨论】：

【解决方案1】：

这听起来更像是一个咆哮而不是一个问题，但要回答：

在那个虚拟场景中，我是否需要编辑所有以前的脚本以确保脚本能够按预期运行？

是的！

您应该始终在脚本（或任何其他可重用代码的 sn-p）中使用完整的参数名称。

部分参数名称、别名和其他快捷方式的自动解析非常方便以交互方式使用 PowerShell。它让我们启动powershell.exe 并执行以下操作：

ls -re *.ps1|% FullName

当我们想要找到配置文件中所有脚本的路径时。非常适合探索！

但如果我要将该功能合并到脚本中，我会这样做：

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

不仅出于您提到的原因，还出于一致性和可读性 - 如果我的同事出现并且可能不熟悉我使用的快捷方式，他仍然能够辨别含义和管道的预期输出。

注意：目前在 GitHub 上有 three open issues 在 PSScriptAnalyzer 中添加警告规则 - 我相信项目维护人员会喜欢这个:-)

【讨论】：

感谢您的回答。这不是咆哮，而是我正在阅读热门书籍“一个月内学习 Windows PowerShell”，而作者没有在脚本中指定此要求。他只是说你可以写短参数等。所以我认为重要的是要知道微软是否有我没听说过的关于这个的东西要说。总之，你说的很有道理。非常感谢。
我找不到任何官方参考资料，但与我讨论过这个话题的每一位相关微软员工和 MVP 都毫不犹豫地同意
编辑：我提到的那本书的作者在本章后面的脚本中提到总是写完整的参数。我只是想更正此信息以给予他适当的信任。
为什么你用Select-Object -ExpandProperty FullName代替% FullName，而不是这个ForEach-Object FullName？
当然，很抱歉耽搁了，因为我对所有这些堆栈溢出问题都不熟悉。我什至不能投票给你，因为我还不允许:)