最近上班在思考这问题
假如今天有个 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

两个都写 把不用的那一个注解掉 但是留着以后维护弹性多了 选择题比申论题好写多了