我正在支持和開發一個大型應用程序。這個問題特別涉及命名約定。.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