命名约定准则值得关注吗？

我使用.Net约定来命名变量：

• camelCase用于变量和字段（我倾向于将_camelCase用于类中的私有字段）
• PascalCase用于方法，属性和类

我唯一偏离的地方是我实际上更喜欢Java SCREAMING_CAPS样式的常量和枚举。

我公司的代码库散布着来自VB6和VBScript的伪匈牙利表示法样式，如果不是成熟的匈牙利语，即

• s或str表示字符串
• 我或诠释为诠释
• d代表小数（有时是双精度）
• o或obj（任何类型的对象）

每当我看到别人的代码中使用了这种代码样式（即使是在未开发的代码中，而不仅仅是旧版代码）时，我都会感到畏缩，而我拒绝自己使用这种样式。过去，我提起过.Net命名约定的标准化，但是它被忽略了-用匈牙利符号书写的人们继续这样做，而我们中不喜欢我的人们继续使用我们自己的风格；我有点担心，如果我们进行标准化（我一直在努力，但似乎没人在乎），它将采用匈牙利符号，而不是推荐的方式，然后我将被迫编写这样的代码。

在这方面，我是不是从暴风雪中爬了出来？我是否应该不在乎代码中是否有多余的标识符，而不是描述性的名称，而是继续使用自己的方式并促使其成为标准？

您唯一需要关心的是，您在一个团队中工作，而人们根本不在乎清理工作。真是可悲。

做您想做的事，继续使用现代风格，并邀请人们（但不要强迫他们）也采用它。当然需要时间。一段时间后，您将看到它是否会在任何地方运行以及下一步可能要做什么。

PS如何安排有关此问题的会议并邀请所有相关人员参加。然后，您将得到他们的充分注意，指出问题并提出您的方法。这将使他们有所思考。也许从您的本地尝试来看，他们并没有非常重视您。

我认为您可能需要问问自己，匈牙利符号是否正在影响您的个人产出/质量，或者仅仅是在损害您的自我。自我，我的意思是，通常情况下一切正常，但是您永远也不想让您外部尊重的人看到可耻的过时代码。尽管我认为关注点确实有其优点，但您必须权衡该关注点与每个不得不转换的人所承受的质量/生产力冲击。

这是一个技术性债务问题，因为您很正确地认为这种风格的匈牙利语在.Net中没有任何意义（“ I”接口除外，但那是另一回事了），但是，这可能是团队可以忍受的技术债务，直到它自然消失。

除了现代的IDE之外，最好的反对匈牙利表示法的方法是认真对待它，它具有大量的方法来显示颜色的类型，可见性和更多颜色的变量，并带有微小的符号和工具提示文本。

• 鼓励更多区别（b）酷（f）浮（c）har（l）ong（s）短（与String冲突？否：（S）tring），（v）oid。
• 鼓励对可见性进行编码。我来自Javaland，希望它也适用于.net：应该使用（pri）vate，（pub）blic，（pro）protected（def）ault。
• .net是否具有final / const？使其为前缀！我听到“不稳定”的声音吗？
• 为什么int和long需要前缀，而不同的对象却不需要前缀？这不合逻辑。创建一个abbrev.tab。每个新对象都有一个不同的缩写。
• 可能为null的变量，也不应为null的变量也可以加上前缀。聪明的人将整个DbC放在变量的前缀中。

认真地讲：在重构时，您可能将变量从int更改为long，从String更改为char。您也不需要更改名称。

在IDE中，您通常会在侧面的框中将名称排序。按名称排序，很容易找到。如果大多数变量都以o或i开头，那么进入名称的显着位置就很不方便。

附加字符会干扰变量的语义。整数“ sane”得到“ i_sane”，它看起来更像“ insane”。

匈牙利语在缺少类型系统的语言中很有帮助。如果编译器强制使用特定类型，则不需要它。如果您用一种移情的“是的，对老年程序员来说，用过去装饰匈牙利语”来修饰您的lamento，那么过去那些老年程序员可能是徒劳的，并且不愿被视为老派。

但是，要使该技术起作用，必须小心。谈到“高级程序员”时，也许您可​​以降低声音，让他们感到，您对他们有多谨慎，他们需要多少照顾。这样房间中的第三个人就会意识到，您正在试图隐藏某些东西，这当然会提高他的好奇心。

购买Framework Design Guidlines的副本，并将其放在经理（或控制代码风格的人）的办公桌上。一定要在显眼位置贴上说明，以突出介绍一致性的重要性。要进一步开车回家，请获得“ 干净代码”的副本，然后在有关编码约定的部分上放入书签。

从某些方面来说，这是一个主观的问题，这是我经过一段时间娱乐然后避免的那些编程细节（拼写？）辩论之一。虽然我认为匈牙利的记法是应予消除的一种罪过，但我认为保持一致性更为重要。

本着这种精神，我将尽力说服一个团队使用以域为中心的变量命名，而不是基于类型的命名约定，但是，如果一切都变得艰难，我将退缩，接受每个人都必须遵守的命名标准通用的代码库。

我不赞成由标准组织强加的一些通用强制性标准，但是软件团队会开发自己的标准，更重要的是，要坚持下去。

使用reshaper重命名变量是如此之快，以至于我可以如此迅速地撤消那些被认为不正确的命名约定，以至于我不必离开那些错误的老旧约定。

如果您没有重构工具，那么，我同意其他评论者的意见，他们建议您尽可能遵循代码库的现有约定，即使使用错误。（到目前为止，有一些变量命名约定，如果允许的话，它们会变成错误生成器）

您的大多数担忧都是正确的，这会使新开发人员的生活变得更轻松，也可能使您更加理智。您应该全部采用的一种约定是描述性名称。您应该能够对此达成共识，而不必根据样式的严重程度而大幅度改变样式。对于其他一切，要么等到您掌管，要么用思考和感觉您的方式的新开发人员替换当前成员。

我的偏差：

• _PublicPropertyBacker
• _private_property_backer
• _privateMember
• CONSTANT_MEMBER
• privateFunction
• param_
• 私有Button okBU; //等等。最多3个字符
• struct SOMESTRUCT //用于拼音结构

通用代码区域和文件布局：

• 会员
  • （私有|内部|受保护|公共）X [静态] X [常量/只读]
• 物产
  • （私有|内部|受保护|公共）X [静态] X [只读]
• 建设者
  • （私有|内部|受保护|公共）X [静态]
• 命令//任何返回void或状态返回的内容
  • （公共|受保护|内部|私人）X [静态]
• 事件处理程序/ private /
  • （控件|远程|服务|其他）事件
• 函数//查询状态，应该没有副作用
  • （公共|受保护|内部|私人）X [静态]