最近上班在思考這問題
假如今天有個 O(log n) 的方法可以寫出一個東西
但是程式碼無法簡化 以後維護的人應該也會很痛苦
因為不直觀
另一個就是程式碼非常簡潔 但就一定是O(n) 甚至 O(n^2)
不知道大家會傾向於哪種?
我個人是比較喜歡clean code 因為過一陣字自己回來維護也比較快上手
但是感覺在學校學這麼多 就是要能寫出效率較好的程式碼

模組化加詳細演算法文件，讓後人決定要不要改。我覺得跟 clean 衝突的通常是開發時間而不是執行效率

O(log n), 然後職責拆分出去，替他寫足單元測試

如果是 critical 的 operation 當然是用 O(log n)

現實情況是,clean跟不是clean的效率差通常只是O(log n）與O(log n)+C的差而已差到級數不一樣的時候，連演算法都不同了，來討論clean不clean的根本沒有意義

如果很頻繁使用到就用比較快的寫法，然後寫說明文件

想都不想...一定選 logn 的, 個人習慣

如果是指像iteration vs. recursion這種情況的話我會寫明這是某種recursion演算法的iteration版本

程式只要讓人看的懂在做什麼就好，不用看的懂那個演算法的

之後要維護的人，應該自己要有能力去確認.

假議題, 要用哪種演算法要用文件說明, 不是讓人看 code自己理解的 = =a

我還是覺得這跟 clean code 無關

用efficency的解法然後寫doc阿*efficiency

演算法不是用code來理解的 你要先profile瓶頸如果不是瓶頸你用效率差但是容易懂的根本無關緊要瓶頸的地方就是用比較好的演算法加上文件

第一個想到的是temmplate programming 編譯出錯的訊息難以言喻 有些語法錯誤甚至要執行才會出現

附上文件的連結啊，有時候使用到特殊的公式，都直接附 url

我覺得程式的重點是後續維護,再來才是效能

看 n 多少啊 XD

data多大？效能不好的點老闆接受度？

這跟clean code 無關+1

看n多大，nˋ真的很大那就是效能優先然後好好寫文件註解

一樓正解，單元拆好你高興實作兩套也沒問題

case by case，該怎麼決定要靠經驗

O(log n)也可以clean code啊

沒有必要極端化啊，捨棄部分效能換取可讀性，或反之。個人覺得這問題是類比的，不是數位的非零即一突然發現log n到n交界點似乎是有點非零即一XD

看n多大+1

這個問題就像問你選擇愛情還是麵包

真正效率瓶頸不在code 在人 開發效率才是重點選哪個? 選存在的那個還沒寫出來的東西就是不存在

會跟時間複雜度放在天秤上取捨的一般是記憶體用量,而不是clean和重構執行的難易度 因為要影響到維護難度的層次是整個軟體的結構大小 而單個演算法通常是不會寫到這麼大量的結構去支持他運作的 如果有 那我會去買人家的library來用(X)

跟clean code 無關+1.

這問題可以很明確的，好比如果程式有 99% 的時間耗在其他部份，只有 1% 時間耗在你的演算法，這時候你把它從 O(n) 寫到變 O(log n) 拿不到顯著的好處。很多時候問題會是出在軟體開發速度和維護性上。

如果最多只有500筆資料要處理，你寫成O(n^5)都沒有關係...

看N多大+1

演算法跟clean code應該無關，還是指程式執行時間？

一定是O(logn) clean code 是誤導用的好效率的code 看不懂的人是他自己的問題 理解力不足現在這時代最需要的是有效率可以最正確達成效果的現在最需要的是不管怎麼混亂的code 都能夠用極快速度理解的能力這才是對的不能期待每個地方的法則都是要維持code看起來漂亮有些地方要的是極快速 但是不看圖無法理解的做法

binomial heap跟Fibonacci heap寫起來都很複雜 相對於隔壁的binary heap......

CleanCode != easyCode成人寫文章不能還在this is a boo

兩個都寫 把不用的那一個註解掉 但是留著以後維護彈性多了 選擇題比申論題好寫多了