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. 是觉得在白板上写会不会最后空间不够
|
