我正在支持和开发一个大型应用程序。这个问题特别涉及命名约定。.NET命名约定
以前的开发人员使用Pascal Casing，强调变量名称和一些其他技术，这些技术似乎在这些日子里被人们所诟病。
我的问题是：我应该继续使用他用于一致性的约定或引入似乎并不在此描述时要皱起眉头约定：在不一致的代价http://www.dofactory.com/reference/csharp-coding-standards.aspx至少一段时间。
我试图重构代码，所以我可能应该在应用程序的新区域中引入新的约定，并继续通过用现代约定替代皱眉约定来重构代码？
也许我正在反思这一点。
如果旧的代码是一致的，保持一致，不同的风格到处都会变得更加混乱。
如果您要更改，请将其作为工作项目，安排并一次完成。
你当然可以找到逐步改变的理由。如果你能说服你自己，你将通过小步骤完成重命名，无论如何你需要处理代码，继续。但说实话，有多少逐渐改变的代码过程在有更新的样式指南行之前完成，并且在清理第一个更改之前以第三种样式开始。
如果您的代码已经处于不一致的风格，那么在更糟的情况出现之前，还有更强制性的理由来清理混乱。
谢谢。目前我没有时间安排这项工作。因此，我应该继续用旧惯例编写代码。然后在稍后的日子，安排一些时间来改变它（包括现在和之后编写的代码）？ – w0051977 2013-03-03 19:13:32
是的，这就是我通常的理由（但也许不是我每天的生活方式）。但是与所有黑白建议一样，在实践中你总是可以稍微细致一点，尤其是如果你有更多的细节指导你的决定。即传统模块和“新”模块，您可以在设计工作中绘制一条线。 – 2013-03-03 19:16:56
我想说，你引用的链接是非常好的起点。多年来我一直在做相当多的.NET开发，而且这篇文章似乎很标准。 – Brian 2013-03-03 19:04:49
@BrianB，你会开始介绍新的公约，而不是以不一致的代价？ – w0051977 2013-03-03 21:22:37
这实际上取决于旧代码的糟糕程度，它有多少以及项目是如何设置的。如果旧代码是使用Java风格的骆驼外壳编写的，那么我更倾向于切换到与核心框架库一致的东西。某种程度的不一致可能是不可避免的，特别是当您使用不同供应商的第三方库时。 – Brian 2013-03-03 23:08:59