在 this老微软文档 Richard Siddaway 表示
I use variable names that are reminiscent of the property name. These variables are arbitrary and you can use any legal variable name – avoid the name of the property though!
这会产生一个如下所示的构造函数
RStimezone(
[int]$idx,
[string]$desc,
[string]$tmzn,
[bool]$crnt
){
$this.Index = $idx
$this.Description = $desc
$this.Timezone = $tmzn
$this.Current = $crnt
}
但没有解释为什么建议采用这种命名约定。据我所知,不存在范围问题,因此使用与类属性同名的参数不会导致问题。在我看来,这是一种更具可读性的方法。
RStimezone(
[int]$index,
[string]$description,
[string]$timezone,
[bool]$current
){
$this.Index = $index
$this.Description = $description
$this.Timezone = $timezone
$this.Current = $current
}
我在这里遗漏了什么吗?
最佳答案
注意:我个人更喜欢描述性参数名称,即使它们碰巧与属性名称冲突 - 但这不是这里的问题:)
我显然不能代表理查德,因为我可以想到为什么有人决定避免方法参数名称与属性名称冲突的两个原因:
避免 future 重构“陷阱!”
该文章写于2016年9月!
大约在那个时候,Visual Studio Code 仍处于起步阶段 - LSP(语言服务器协议(protocol))几乎没有标准化。
这意味着在许多编辑器中(包括 PowerShell ISE,也许还有 SAPIEN PowerShell Studio),PowerShell 的正确上下文“语言支持”纯粹是语法上的,并且在许多情况下基于劣质的正则表达式分词器。
基于 .NET 的编辑器可以利用 PowerShell 3.0 中引入的新 Parser/AST API,但这有点困难,因为 3.0 后的语言还做了一些语法调整隐式属性参数、文字数组处理等。
因此,到 5.0 出现时,该语言唯一的重大变化是引入了 class
和 enum
类型定义语句,很少有编辑器能够快速完成实现对这些新(且稍微复杂)功能的完全支持 - 因为语言的其余部分实际上是相同的,并且许多语法分析器有点可以工作。
你说这与命名方法参数和类属性有什么关系?
好吧,想象一下语法分析器尝试对下面(有效)构造函数中的 $myString
参数进行变量重命名操作:
class MyClass
{
[string]
$myString
MyClass([string]$myString)
{
$this.myString = $myString
}
}
一个简单的重构工具会给你留下这个(无效的)构造函数:
class MyClass
{
[string]
$renamedString
MyClass([string]$renamedString)
{
$this.myString = $renamedString
}
}
cargo 崇拜
正如文章旁注所述,Richard 在 2016 年已经拥有超过 25 年的 IT 经验,我可以向您保证,他职业生涯的很大一部分时间都在与 C# 打交道。
如果我向您展示 C# 中的等效模式,从可读性的角度来看,为什么不鼓励这种特定类型的命名冲突/重叠可能会变得显而易见:
class MyClass
{
private string myString;
MyClass(string myString)
{
this.myString = myString.Substring(Math.Min(1, myString.Length));
}
string SomeMethod()
{
return myString;
}
}
在上面的类中,裸标记 myString
现在代表两个不同的值,具体取决于您正在查看的方法主体。如果您认为“这并不奇怪,我可以很好地阅读它”,请进行图灵测试,因为您可能是编译器;-)
关于Powershell 类 : property vs argument naming,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/60865431/