我一直在這個項目上工作了一段時間，它已經變成了大約2000行。它是以這樣的方式完成的，但它對於某人來說是絕對的噩夢（除了我之外）。所以我着手模塊化代碼並使其更容易理解，現在它已經接近3000行了！擁有更少的代碼但更少清晰，更多代碼和更清晰的代碼會更好嗎？
它最終實現了相同的目標，但我使操作流程更直觀，更容易修改（您將難以改變任何事情並使其仍然可以在以前的版本中運行）。
所以我的問題是：哪個更好？我經常在這裏說人們如果可以用更少的線做同樣的事情，那麼它往往會更好，但程序員友好的方面也很重要。
我可能實際上看到較小的一個是否通過計時來運行更快，這可能很有趣。我很確定第二個版本因爲新設計而更大，而不僅僅是增加了空白。
這取決於代碼應該很容易閱讀不妨礙。
當性能很重要時，可能需要一些不明確的代碼。
否則，更易於理解的代碼更好，尤其是在與其他人一起工作時。畢竟，代碼讀取的次數比寫入次數要多得多。
無疑，當你未來的變化
對於任何編譯語言來說，像註釋，空格和變量名稱這些內容最終都不重要，所以將它們作爲一個很好的工具來提高清晰度。對於你認爲運行速度更快，但看起來更加混亂的代碼部分，請使用這個優勢。
還要考慮一段代碼在運行時被傳遞了多少次，如果它很多，新代碼結構需要多少額外時間。在大多數情況下，電腦會實際運行操作的相同數量的代碼，兩個不同的結構，例如：
// Code Snippet 1...
foo = (bar == true) ? 'Yes' : 'No';
// Code Snippet 2...
if(bar == true) {
foo = 'Yes';
} else {
foo = 'No';
}
希望這有助於！
更多代碼和更清晰。清晰度應該總是第一位。代碼具有雙重功能，讓機器執行它並讓人們閱讀和理解它。沒有後者，前者幾乎是無用的。
清晰度很重要，所以人們可以正確地驗證和/或修改代碼，但這並不一定意味着「更多」的代碼。我的感覺是，通常較少的代碼更清晰。無論如何，評論應該清晰明瞭，不要喋喋不休地被忽略。
更多的代碼，更容易閱讀將永遠贏得我的書。想象一下，當你或其他人必須從現在起3-6個月的時間裏拿起這個代碼，當一切都被遺忘時，會引入多少錯誤。 –
使其可讀。或多或少的代碼對我來說都是無用的（你可以有很多代碼，但仍然很難閱讀）。 –