e*******s 发帖数: 1979 | 1 我有这样的习惯, 觉得思路更清晰,
不知道面试的时候u 这样做好不好
1。 是担心浪费时间
2. 是觉得在白板上写会不会最后空间不够 |
T******g 发帖数: 790 | |
z******g 发帖数: 271 | 3 感觉self-contained代码比较好
逻辑比较复杂的循环可以写invariant |
t********5 发帖数: 522 | 4 之前我问我们组的team lead为什么我们组的代码里几乎没有注释
他说过一句话我觉得很好 :)
“好的代码应该是简单易懂的 需要看注释才能看懂的代码不是好代码” |
p***y 发帖数: 637 | 5 同意你们领导的
说法。
我见过太多反面典型了,凡是注释冗长的。都是有问题的,有的注释直接就说,这么做
是错的,但你别改,改了影响面太大。。。
【在 t********5 的大作中提到】 : 之前我问我们组的team lead为什么我们组的代码里几乎没有注释 : 他说过一句话我觉得很好 :) : “好的代码应该是简单易懂的 需要看注释才能看懂的代码不是好代码”
|
n******n 发帖数: 12088 | 6 扯蛋。简单易懂没有统一标准。
【在 t********5 的大作中提到】 : 之前我问我们组的team lead为什么我们组的代码里几乎没有注释 : 他说过一句话我觉得很好 :) : “好的代码应该是简单易懂的 需要看注释才能看懂的代码不是好代码”
|
d********t 发帖数: 9628 | 7 扯淡,你要写个DP难道要maintain的人都懂吗?
【在 p***y 的大作中提到】 : 同意你们领导的 : 说法。 : 我见过太多反面典型了,凡是注释冗长的。都是有问题的,有的注释直接就说,这么做 : 是错的,但你别改,改了影响面太大。。。
|
z****e 发帖数: 54598 | 8 生产代码你用过dp?
牛逼
【在 d********t 的大作中提到】 : 扯淡,你要写个DP难道要maintain的人都懂吗?
|
s**x 发帖数: 7506 | |
t**********h 发帖数: 2273 | 10 用过一次
【在 z****e 的大作中提到】 : 生产代码你用过dp? : 牛逼
|
|
|
m********s 发帖数: 55301 | 11 绝对不如多和头领们一起喝酒一起看舞蹈好使。
【在 e*******s 的大作中提到】 : 我有这样的习惯, 觉得思路更清晰, : 不知道面试的时候u 这样做好不好 : 1。 是担心浪费时间 : 2. 是觉得在白板上写会不会最后空间不够
|
f******n 发帖数: 198 | 12 你lead是不是忠实执行agile process的那种?说好的code不用写注释,就像说只要有
足够的unit test就可以continuously refactor。理论上听着很美好,实际上根本行不
通。每给dev都觉得自己的code很简单易懂,test coverage很充分。
【在 t********5 的大作中提到】 : 之前我问我们组的team lead为什么我们组的代码里几乎没有注释 : 他说过一句话我觉得很好 :) : “好的代码应该是简单易懂的 需要看注释才能看懂的代码不是好代码”
|
w**z 发帖数: 8232 | 13 自己码的半年后也看不懂了。有时候会感谢自己当时写了注释。
【在 f******n 的大作中提到】 : 你lead是不是忠实执行agile process的那种?说好的code不用写注释,就像说只要有 : 足够的unit test就可以continuously refactor。理论上听着很美好,实际上根本行不 : 通。每给dev都觉得自己的code很简单易懂,test coverage很充分。
|
t********5 发帖数: 522 | 14 当然不是一行注释都没有 通常有注释的就是比较tricky的东西 譬如涉及到比较奇葩的
概率计算或者非常复杂的算法的部分的
除此之外大部分的事物逻辑都是自解释的代码
【在 f******n 的大作中提到】 : 你lead是不是忠实执行agile process的那种?说好的code不用写注释,就像说只要有 : 足够的unit test就可以continuously refactor。理论上听着很美好,实际上根本行不 : 通。每给dev都觉得自己的code很简单易懂,test coverage很充分。
|
s******y 发帖数: 416 | 15 你看不懂DP?
【在 d********t 的大作中提到】 : 扯淡,你要写个DP难道要maintain的人都懂吗?
|
i***l 发帖数: 468 | 16 理想化了,不要注释这个有点偏激。必要的注释当然需要。不然干嘛要做
documentation? 以后review自己的code都吃劲。
【在 t********5 的大作中提到】 : 之前我问我们组的team lead为什么我们组的代码里几乎没有注释 : 他说过一句话我觉得很好 :) : “好的代码应该是简单易懂的 需要看注释才能看懂的代码不是好代码”
|
r***s 发帖数: 737 | 17 在 c++里一堆 pointer arithmatic 也不写注释?
distributed system里面几个部分共同实现一个 protocol的也不写?
有 state transfer graph做design的, 代码里也没注释?
你们丫的狂妄自大到一定程度了
【在 p***y 的大作中提到】 : 同意你们领导的 : 说法。 : 我见过太多反面典型了,凡是注释冗长的。都是有问题的,有的注释直接就说,这么做 : 是错的,但你别改,改了影响面太大。。。
|
L***s 发帖数: 1148 | 18 我一般努力让代码self-explanatory,比如命名上多下功夫;
再如多拆函数(尽量避免超过10行的函数,单元测试也方便),
函数名本身就是很好的文档。
我尽量避免注释,要注释也主要在两个地方:
一是在重要的类或函数的定义处,讲清大体思路;
二是一些不注释就看不懂的tricky细节——这种情况很少。 |
z****e 发帖数: 54598 | 19 其实我觉得码农写的注释真没啥用
表达能力一塌糊涂不说,还一堆错
有时候代码改了,注释没改,反而误导
【在 r***s 的大作中提到】 : 在 c++里一堆 pointer arithmatic 也不写注释? : distributed system里面几个部分共同实现一个 protocol的也不写? : 有 state transfer graph做design的, 代码里也没注释? : 你们丫的狂妄自大到一定程度了
|
a*****u 发帖数: 1712 | 20 没必要,除非特别tricky的
★ 发自iPhone App: ChineseWeb 8.7
【在 e*******s 的大作中提到】 : 我有这样的习惯, 觉得思路更清晰, : 不知道面试的时候u 这样做好不好 : 1。 是担心浪费时间 : 2. 是觉得在白板上写会不会最后空间不够
|