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

[go522000]

截一张图给大家感受一下。 https://static01.imgkr.com/temp/372735ce126444a283e8856dd5a4c56e.png

没办法修改，实在想不通这个同事是什么意思。 是对自己代码的自信？ 还是故意留坑？

唉，我自己 15 号也要走了，只能和大老板说自己能力有限，无能为力。

[cryboy007]

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

[liudaolunhuibl]

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

[Jooooooooo]

代码没有业务逻辑的注释写的再漂亮也不行.

[jackbrother]

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

[zengzizhao]

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

[yiqiao]

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

[Zhengqing]

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

[yanqing07]

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

[sun019]

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

[v2lf]

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

[v2lf]

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

[mengzhuo]

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

[vainl1]

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

[Biexl]

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

[panlatent]

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

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

---

说点别的

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

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

[DCELL]

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

[ETO]

这代码写得还可以呀

[cxshun]

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

[zw1one]

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

[reneiw]

就这断行，超级恶心