代碼庫中我的工作有使用冗餘方法是最佳實踐：從外部庫
if (!Directory.Exists(dir))
{
Directory.CreateDirectory(dir);
}
幾個例子根據MSDN文檔（http://msdn.microsoft.com/en-us/library/54a0at6s(v=vs.110).aspx），這是多餘的，因爲createDirectory不會覆蓋一個現有的目錄。
這可以被視爲使代碼更清晰，因爲從.CreateDirectory(dir)方法中不明顯這是行爲。另一方面，這是代碼膨脹並且保持它（即使將它添加到庫/實用程序類）也有問題（例如，您必須讀取/維護更多行代碼）。
這裏認爲最佳實踐是什麼？
它可能看起來多餘，但我可以看到有人決定走這條路的原因。
的主要區別是：
Directory.Exists()回報只是boolDirectory.CreateDirectory()回報DirectoryInfo所以即使在目錄中存在，存在執行吃出DirectoryInfo情況下，額外的工作，這可能根本不需要。
出現的另一件事是，你必須知道，Directory.CreateDirectory不覆蓋目錄，如果它存在！即使有人不知道他可以很容易地弄清楚這段代碼是怎麼回事，也可以撥打Directory.Exists。我不認爲這裏有best practice。
就我個人而言，我通常會刪除多餘的代碼。
這可以被看作是使代碼更清晰，因爲從.CreateDirectory（dir）方法中不明顯，這是行爲。
總的來說，我認爲通過評論會更好，而不是冗餘代碼路徑。添加額外的代碼以避免缺乏知識似乎是包含檢查的一個薄弱的理由。
這就是說，在避免調用CreateDirectory時會有潛在的（非常小的）性能增益，因爲該方法將構造一個DirectoryInfo實例。在實踐中，這很可能是「噪音」（因爲無論如何，IO調用往往相對昂貴），所以它不是我會考慮到等式中的東西，除非它被證明是一個衡量問題。
我完全同意那些看起來很奇怪的評論代碼（爲什麼前面的程序員不檢查這個目錄是否先存在？）對於沒有完全理解方法內部工作的人來說總是一個好習慣。 –
即使初步檢查已通過，競爭條件也可能導致創建目錄失敗。 因此，我認爲這段代碼不正確，我勸你不要使用它。
我同意 - 除非在這種情況下，只要您嘗試*使用*目錄就會出現相同的競爭條件 - 在這種情況下，真正的問題會發生在文件寫入上（就像它應該） 。 –
'Directory.CreateDirectory（）'如何防止競爭條件？在創建之前，它在內部仍然存在檢查。 – DaveShaw
@DaveShaw：.NET「CreateDirectory」在內部調用本機Win32函數「CreateDirectory」，如果指定的目錄已存在，則返回ERROR_ALREADY_EXISTS。 –
'createDirectory不會覆蓋和現有目錄'，雖然這是真的，但是如果目錄* does *存在，它仍然會拋出一個異常？我現在沒有能力測試它，但我認爲'if'是爲了防止在這個塊上出現'IOException'。 –
@EvanL Nope - 它只是返回沒有問題的信息 –
沒有'Directory.Exists'代碼會導致我暫停和檢查它。即使那不是我當時正在處理的事情。我更希望檢查能夠幫助開發人員閱讀代碼，認爲這裏沒有任何東西可以看到。 – cgTag