如何避免瘋狂的命名約定？

它是共同命名的程序集一個名字，命名組件中的另一內部的文件夾，然後開始進行這些文件夾內的名字進入類？例如：如何避免瘋狂的命名約定？

Project.Presenter 
    Carriers 
     CarriersFindPreferedCarriersPresenter.cs 
     CarriersPreferencesPresenter.cs 
     PreferredTargetLocationPresenter.cs 

Project.Service.Fixture 
    Carriers 
     CarriersServiceFixture.cs

或執行本futher，甚至方法，如這樣的：

List<PreferredTargetLocationPresenter.PreferredTargetLocation> 
newlyAddedPreferredLocations = new 
List<PreferredTargetLocationPresenter.PreferredTargetLocation>(); 

newlyAddedPreferredLocations.add(destinationLocation.PreferredCity);

對我來說這似乎變得更加和你在一個項目上再工作，並開始增加更多的困惑額外的組件和方法。有沒有更好的方法來處理這個問題？

任何反饋將受到歡迎。

來源

2010-02-09 Chris

的Pragmatic Programmers推廣乾的原則：不要重複自己。這也適用於命名。一次又一次重複相同的範圍名稱或前綴不會添加任何更多信息，只會使名稱更長，更不可讀，更容易輸入錯誤並難以搜索。如果你有100個以PreferredLocation*開頭的類名，那麼你將很難找到合適的名稱:-(

所以我完全反對這一點，類和方法名的範圍由封閉的路徑/項目名稱在java中，這將是package，在C＃中，我不知道什麼是合適的名詞），所以如果你需要關於類/方法的下落的所有信息，就足以看看它的完全限定名稱。在常規代碼中，不應該強制使用全名，除了名稱衝突外，我認爲這應該被視爲例外而不是規則。

此外，在設計良好的應用程序，大多數方法/類不是全局可見的，只有insi他們各自的軟件包（在編程語言允許的地方--Java，我相信C＃也是如此）。這減少了名稱衝突的風險，並進一步避免了類名前綴的需要。

來源

2010-02-09 21:00:18

提及範圍界定/全球知名度+1 – Tanzelax 2010-02-09 21:05:05

問一百個不同的人這個問題，你會得到一百個不同的答案。我喜歡用任何方法編寫/維護代碼最簡單的方法，一半是描述性的長名稱，另一半是簡短而甜美的名稱。只要代碼直觀靈活，我就無法看到任何問題。

來源

2010-02-09 20:51:10

有時候，你將不得不使用更長的名字，但你通常要保留名稱儘可能短。關鍵是要有描述性的名稱，這些名稱提供了足夠多的細節，而且沒有更多。

來源

2010-02-09 20:52:48

是PreferredTargetLocationPresenter.PreferredTargetLocation的PreferredTargetLocationPresenter類型的子類型？換句話說，你是否在嵌套類？

如果是的話，你可能會更好打破PreferredTargetLocation到自己的類。這允許你寫：

List<PreferredTargetLocation>

，而不是

List<PreferredTargetLocationPresenter.PreferredTargetLocation>

如果您正在使用C＃3.0中，您可以通過使用var進一步縮短聲明：

var locations = new List<PreferredTargetLocation>();

來源

2010-02-09 20:53:39

主講就像是一個管理器，它具有當演示者被實例化的第一次與UI被裝載PreferredTargetLocation的性質。 – Chris 2010-02-09 21:17:58

如何避免瘋狂的命名約定？

回答

相關問題