准备修改离职同事的一个项目，所有代码只有开头一行注释，看着头晕。

这个命名看着挺舒服的，似乎也不是很需要注释吧

个人觉得注释并不是越多越好，最舒服的代码是通过合理命名就能看懂意思，根本不需要注释

这不是看着还行吗，还需要啥注释？

你们公司允许就这么把代码贴出来?

这代码很差？

除了方法上注释不要使用单行注释，其他没什么问题。这个业务逻辑感觉挺简单，写的也很清晰

这就当一个黑盒，不也没啥问题啊

连个业务逻辑相关的说明都没有，那么多人觉得这叫还行？可能我水平不够，所以只能在写代码时多加注释了

这业务代码确实需要多注释文档才容易理解。不然要花很多时间。可能改成面向对象的写法好点。

你有时间发帖，却没时间怼他？

这 PHP 写的挺干净的。

向支持不用注释的各位请教一下，第 619 行，JoinService::JoinField(...) 这个函数里面大约还有 40 多行代码（整个文件都没注释），大家在不把代码过一遍的情况下，能不能猜出这一行是什么意思呢？最后会返回什么内容呢？

@haah 哈，不怼他，我还有 9 天也离职了，直接告诉老板我能力有限最方便了。

@go522000 就是 useraddress 存的是 province_id city_id ， 要 join 表查一下对应的 province_name city_name 这些吧
其实这种通用的业务规则还好 那种专有的业务规则不写注释才是会死人的

我觉得写的挺好的……

@go522000
都要走了还改啥啊.把图删了吧,别让你们老板抓住把柄.

说实话这代码比绝大多数屎山强太多 最要命的其实不是这个 JoinService 顶天了点进去看一遍 反而是 $flag, getCode, $data 这些名字 比如$flag == 0 的判断虽然可以从 if 里看出应该是判断发货还是收货的 这样的变量名其实毫无意义 还不如 abcd 至少写的人会有愧疚感

删图吧

我觉得写的挺好的……

这种代码一看就好理解，那种大神写的奇巧淫技才看不懂呢

说烂不至于，说它很清晰可就算了吧。
这么一大堆业务逻辑，不做分段注释，也不做进一步的函数封装。代码里也有明显的分段，每一段稍微注释一下不难吧？

@go522000 根据变量名字，地址信息，然后后面的省市 ID ，差不多根据 id 找到更具体的省市信息，这一段也需要注释么？

不过，注释写的肯定很差，输入输出起码写，每一个关键变量和业务逻辑起码加一个，619 行这样的不需要注释。

代码挺整洁的,个人觉得并不需要太多注释

以及程序员最讨厌别人不写注释,同时最讨厌自己写注释

注释和文档由于会因为代码变更缺乏维护而辞不达意,更好的做法还是把代码结构写清晰,变量名说清楚

说还行的原因是，起码根据变量名字，方法名字，几乎已经看明白这些代码准备干什么，难道说个还行都过分么？

又不是不能用，建议各位熟读 https://coderlmn.github.io/frontEndCourse/unmaintainable.html

提升自己核心竞争力。

作为多年的 Phper ，这代码写的，确实还不错

作为多年的 Phper ，这代码写的，确实还不错

并不是注释越多越好啊。。。。

这代码还要注释？
@go522000 619 应该是返回一个集合，包含省市区的地址（字符串）。这个有啥看不懂的？

小伙子，你太年轻了。
至少变量命名清晰，结构也不乱。
你是没有见过糟糕的代码！

就这么把公司代码发出来，建议删帖&拉黑

@really28 大佬，看了下，真是牛逼坏了呀

看着还行。

你把屏幕整宽点，去掉软换行，就会发现还挺整洁的，基本都是参数转化和提取而已。

这就看懵了？？？小伙子，你太年轻了。1000 行没有注释的 SQL 就问你怕不怕！！！话说 SQL 没注释也正常。

后续还是不要贴代码吧，严重违背职业道德

代码看完后 感觉还行能猜到百分之 8 90%了，还是太年轻 有的代码看完以后 不知所云 让人欲仙欲死

这已经算好的了 。。

@ZoR 觉得还行的才是久经沙场，比起代码缺注释，数据库字段缺注释的老项目都有很多

觉得挺好的，命名和很规范

你应该需要这个需求的需求文档、设计文档等等，这些文档里的内容加上这个代码足够，总不能我把需求背景和设计思路都写在代码里吧

有注释不代表是好代码，好的代码让你一眼就能看出来它是做什么的。说实话，反而是代码越不清晰的情况下，才需要去刻意注释，因为写下这段代码的人都可能不知道它在做什么。

业务逻辑说明要写在代码的注释里？
难道不应该去看需求文档、设计文档之类的文档吗
如果业务逻辑很复杂，岂不是要把文档粘贴一份到代码里才叫好？

能看懂，不过还是可以改进的
第一个 flag 判断是写的一样的代码吗？
看起来是顺序和参数不一样，再封装一下不就可以共用了吗？
我也同意注释不用写到代码里，这通常是未实现功能或者是放到 TODO 里面，做完就删了。

给院长和导师同时发一封邮件就好了 院长和导师的邮箱都很好找的

坐等 LZ 去新公司后的吐槽~
我就放下话了，新公司代码肯定比这个差~哈哈哈哈

这代码写的规矩 算不错的了

@BiChengfei 这好像是 php ， 每种语言风格不同吧，go 源码单行都比较多

说实话，这个还行。 要是功能再细化和内聚，就更美啦。
而且，注释多也不一定好，有些真是废话连篇

写得挺舒服的啊，这都算屎山的怕是没见过真屎山。
某鹅某业务那 800 行带视图的 SQL+乱封装的代码是真开眼了

@really28 复议一个 How to Write 3v1L, Untestable Code
https://testing.googleblog.com/2008/07/how-to-write-3v1l-untestable-code.html

你可能没见过更头痛的代码。当然了如果可以把这一大段代码拆分成多个 function ；将 0 ，1 使用常量或枚举定义；以及个别无含义的变量名改改。在没有 review 的情况下，这种业务代码基本不太会动了。

总体上还算比较清晰，能看出来做什么 。但如果能改进一下或者加点注释能够节省其他人的时间，命名有点偷懒，函数行数多多，应该拆分成多个函数。里面的空行好评。

好的代码应该是不需要或很少需要注释的，注释只是手段，最终还是为可读性服务。 而且有的时候写业务恰饭的时候，每那么多时间和精力去顾虑太多，及格或者良就差不多了。

---

说点别的

对于 PHP 来说，注释（ PHPDoc ）很多时候还为 IDE 、文档生成器以及测试框架服务，这方面最好多注意下。PHP 是动态类型，早期语言特性不丰富（类型标注），IDE 支持有限，只能通过加 PHPDoc 来优化编码体验。现代 PHP 已经在绝大多数地方支持类型标注，以及支持注解。PHPStorm 以及部分测试框架甚至提供有限的泛型支持。

利用好代码检查，没有警告，包括没有拼写错误。当在 IDE 中想要用到某段代码却不能获得智能补全（或提示）时，就要考虑代码（注释）是不是可以再优化优化或者换 IDE 了。

我的同事要是代码都写这样，我都能笑醒

这代码写得还可以呀

感觉代码命名啥的挺舒服的，而且逻辑也不复杂，这水平很不错了，不需要啥额外的注释啊

写得很好 代码即注释 觉得看起来不直观你可以补注释

就这断行，超级恶心

没注释 不知道加上注释啊，又不是什么复杂的算法和逻辑……加一些注释的事情，何必要辞职

我个人有个几年前的项目，已运行好几年了，早忘了怎么写得，为什么这么写，那些代码注释全面，包括所有的 if 都给注释上了，前段时间客户让我改个小地方，看注释迅速熟悉项目，找到问题，半天搞定。
如果没有注释，碰到每次隔一年多，要修改某处的情况，每次修改都要重复浪费时间再熟悉项目。有时时间成本会高到无法再去修改。

注释越多，理解越省力，否则改起来需要先花很多时间熟悉业务。
注释是否划算，要看这个人是不是几年后还会修改这个项目了。

上面说的是纯个人项目，注释非常详细，公司的项目我注释就少多了，每个函数简要注释下用途，少数难点也注释下即可。

(你同事上不上 v2

@really28 真有意思
Quidquid latine dictum sit, altum sonatur.
(随便用拉丁文写点啥都会显得高大上。)

@really28 复议一下原文 https://www.mindprod.com/jgloss/unmain.html