我应该在C#中使用匈牙利应用程序表示法吗？

概述我知道这个问题已经被问了一下,从它的外观来看,这个问题没有明确的是或否答案,但是,我仍然对某些事情感到困惑. 通常在我编程时,我遵循一些关于前缀的规则： > m_在成员面前 > p_在物业面前 > s_在静态面前 > a_在参数前面 > l_在局部变量前面 我现在有一份新工作,我注意到代码中没有使用前缀.我问为什么,他们回答说IDE完成了跟踪成员变量是什么以及什么是局部变量的所有工作.现在我在想, 我知道这个问题已经被问了一下,从它的外观来看,这个问题没有明确的是或否答案,但是,我仍然对某些事情感到困惑.

通常在我编程时,我遵循一些关于前缀的规则：

> m_在成员面前
> p_在物业面前
> s_在静态面前
> a_在参数前面
> l_在局部变量前面

我现在有一份新工作,我注意到代码中没有使用前缀.我问为什么,他们回答说IDE完成了跟踪成员变量是什么以及什么是局部变量的所有工作.现在我在想,可能是这样,但是使用前缀不是更容易吗？

我的意思是,如果我有一个成员,一个静态和一个名为“机器人”的局部变量,在编写方法时引用它是不是很麻烦？这可能是一个不切实际的例子,但我喜欢在我的头脑中设置一个良好的规则,即使是在不切实际的条件下,我也可以始终如一地应用.

这个例子是否适合使用匈牙利表示法？

我想我会制作一个优点/缺点列表并在我了解更多信息时对其进行编辑.

反对匈牙利人的论点：

Class.Robot或机器人

this.robot

机器人

不需要匈牙利人.

计数器：

仍然存在不一致性,机器人在不同的方法中可能意味着不同的东西.为了保持一致,你应该在每个Robot变量之前为Class或this(或没有)添加前缀.

最重要的是,假设你想要访问静态变量StrawBerry,你怎么知道名为StrawBerry的成员变量没有定义？也许它是在另一个你看不到的文件中定义的,所以你可能会得到意想不到的结果.现在您可能会说这是通过IDE可见的,但我认为使用前缀是优越的,因为您看到了您正在引用的内容,而您可能会错过IDE告诉您的内容.当然,您也可以使用此/ Classname前缀,但这种做法违背了不使用匈牙利表示法的目的.

反对匈牙利人的论点：

当在字段和变量的命名中使用匈牙利表示法时,会违反此规则.在C代码中使用匈牙利表示法已经很普遍,但C#中的趋势是为变量使用更长,更具描述性的名称,这些名称不是基于变量的类型,而是描述变量的用途.

计数器：

我提到的前缀不是基于变量的类型,前缀实际上指定了变量的用途.

反对匈牙利人的论点：

现代代码编辑器(如Visual Studio)可以轻松识别变量或字段的类型信息,通常是将鼠标光标悬停在变量名称上.这减少了对匈牙利表示法的需要.

计数器：

虽然这是真的,但除非发生错误,否则我自己几乎不会将鼠标悬停在变量名称上方.相反,使用匈牙利表示法,您可以立即看到变量在类中的位置.

备注：

Microsoft不推荐使用匈牙利表示法来表示文件名吗？我读到接口文件前缀为I是一种惯例,这是匈牙利表示法的一种形式.虽然这与我上面的问题没有直接关系,但它确实提出了有时建议使用匈牙利符号的观点.

解决方法 不,不要这样做.它使代码更难阅读.如果你用每个带有v_的动词和带有n_的每个名词写英文,这会使句子更难以阅读,同时添加大多数时候无用的信息.

如果你的类设计得很好,责任和方法都很少,那么从名称和使用它的上下文中找出每个变量的含义应该不难.当它不明显且您需要知道时,很容易发现：您可以将鼠标悬停在变量名称上,或按“转到定义”.

Stylecop有一个rule,当你使用匈牙利表示法时会发出警告.规则描述对该规则存在的原因有一点解释：

> Typename FIEldnamesMustNotUseHungarianNotation
> CheckID SA1305
>类别命名规则

原因

C#中的字段或变量的名称使用匈牙利表示法.

规则说明

当在字段和变量的命名中使用匈牙利表示法时,而是描述变量的用途.

此外,现代代码编辑器(如Visual Studio)可以轻松识别变量或字段的类型信息,通常是将鼠标光标悬停在变量名称上.这减少了对匈牙利表示法的需要.

总结

以上是内存溢出为你收集整理的我应该在C#中使用匈牙利应用程序表示法吗？全部内容，希望文章能够帮你解决我应该在C#中使用匈牙利应用程序表示法吗？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。