我知道这个问题已经被问了一下,从它的外观来看,这个问题没有明确的是或否答案,但是,我仍然对某些事情感到困惑.
通常在我编程时,我遵循一些关于前缀的规则:
m_在会员面前
p_在物业面前
s_在静态面前
a_在参数前面
l_在局部变量前面
我现在有一份新工作,我注意到代码中没有使用前缀.我问为什么,他们回答说IDE完成了跟踪成员变量是什么以及什么是局部变量的所有工作.现在我在想,可能是这样,但是使用前缀不是更容易吗?
我的意思是,如果我有一个成员,一个静态和一个名为"机器人"的局部变量,在编写方法时引用它是不是很麻烦?这可能是一个不切实际的例子,但我喜欢在我的头脑中设置一个良好的规则,即使是在不切实际的条件下,我也可以始终如一地应用.
这个例子是否适合使用匈牙利表示法?
我想我会制作一个优点/缺点列表并在我了解更多信息时对其进行编辑.
反对匈牙利人的论点:
Class.Robot
要么 Robot
this.robot
robot
不需要匈牙利人.
计数器:
仍然存在不一致性,机器人在不同的方法中可能意味着不同的东西.为了保持一致,你应该在每个Robot变量之前为Class或this(或没有)添加前缀.
最重要的是,假设你想要访问静态变量Strawberry,你怎么知道名为Strawberry的成员变量没有定义?也许它是在另一个你看不到的文件中定义的,所以你可能会得到意想不到的结果.现在您可能会说这是通过IDE可见的,但我认为使用前缀是优越的,因为您看到了您正在引用的内容,而您可能会错过IDE告诉您的内容.当然,您也可以使用此/ Classname前缀,但这种做法违背了不使用匈牙利表示法的目的.
反对匈牙利人的论点:
当在字段和变量的命名中使用匈牙利表示法时,会违反此规则.在C++代码中使用匈牙利表示法已经很普遍,但C#的趋势是为变量使用更长,更具描述性的名称,这些名称不是基于变量的类型,而是描述变量的用途.
计数器:
我提到的前缀不是基于变量的类型,前缀实际上指定了变量的用途.
反对匈牙利人的论点:
现代代码编辑器(如Visual Studio)可以轻松识别变量或字段的类型信息,通常是将鼠标光标悬停在变量名称上.这减少了对匈牙利表示法的需要.
计数器:
虽然这是真的,但除非发生错误,否则我自己几乎不会将鼠标悬停在变量名称上方.相反,使用匈牙利表示法,您可以立即看到变量在类中的位置.
备注:
Microsoft不推荐使用匈牙利表示法来表示文件名吗?我读到接口文件前缀为I是一种惯例,这是匈牙利表示法的一种形式.虽然这与我上面的问题没有直接关系,但它确实提出了有时建议使用匈牙利符号的观点.
不,不要这样做.它使代码更难阅读.如果你用每个带有v_的动词和带有n_的每个名词写英文,这会使句子更难以阅读,同时添加大多数时候无用的信息.
如果你的类设计得很好,责任和方法都很少,那么从名称和使用它的上下文中找出每个变量的含义应该不难.当它不明显且您需要知道时,很容易发现:您可以将鼠标悬停在变量名称上,或按"转到定义".
StyleCop有一个规则,当您使用匈牙利表示法时会发出警告.规则描述对该规则存在的原因有一点解释:
TypeName FieldNamesMustNotUseHungarianNotation
CheckId SA1305
类别命名规则
原因
C#中的字段或变量的名称使用匈牙利表示法.
规则说明
当在字段和变量的命名中使用匈牙利表示法时,会违反此规则.在C++代码中使用匈牙利表示法已经很普遍,但C#的趋势是为变量使用更长,更具描述性的名称,这些名称不是基于变量的类型,而是描述变量的用途.
此外,现代代码编辑器(如Visual Studio)可以轻松识别变量或字段的类型信息,通常是将鼠标光标悬停在变量名称上.这减少了对匈牙利表示法的需要.