代码要写注释吗？写你就输了

如何看待程序员不写注释/h3>

“几个月前，我写的代码只有我和上帝知道”

“现在，只有上帝知道了”

最近在知乎上看到了这个话题：怎样看待程序员不写注释看了下浏览量居然有 30+w 次，看来大家讨论的挺热闹，我浏览了大部分的回答，发现大家的观点可以归纳为以下几点：

1. 不写注释就是害人害己，别人看不懂，过几天连自己也看不懂
2. 好的代码就是最好的注释，我的代码可读性很好，没必要写注释
3. 只要有完善的文档，代码本身就是注释
4. 自己写代码时：“我自己写的代码还要写注释 看别人的代码时：“卧槽这人居然不写注释

对于程序员群体，有位知乎 友的总结非常到位：程序员最讨厌的四件事：1. 写注释 2. 别人不写注释 3. 写文档 4. 别人不写文档，不得不说我们程序员群体真是个可爱而又敢于自黑的群体。

我们写代码不仅仅是只给编译器看，还要给自己身边的同事看，假如有一天休假，你把工作交接给了你的同事 会王，你正吃着火锅唱着歌呢， 会王因为帮你解决 Bug 而又看不懂你的代码，给你来个夺命连环 Call，你还有什么心思度假。有人也会说：“我自己写的代码只要我自己看的懂就行”，可事实上不写注释，时间一久，等需要重新拾起来的时候你就会发现：“卧槽，这是啥为啥 错”。所以给代码添加合格的注释不仅能够让别人更快速的接手你的代码，也能更快的让拾起自己的代码。

雷军 23 年前写的代码

如何优雅的为程序写注释/h3>

“好的代码不需要注释”不等于“没有注释就是好的代码”，好的代码不需要注释的前提是后面阅读你代码的人水平不能比你差太多，要写出那种新人都能看懂的代码，实在是太难了。

注释风格

// 或者 /// 或 /* */ 都可以; 但 // 更 常用， 要在如何注释及注释风格上确保统一。

文件注释

文件注释的顺序应该如下：

1. 文件内容的简要描述
2. 日期
3. 版权信息声明，例如：Copyright 2008 Google Inc。 必要的话还可以加上许可证样板，例如：Apache 2.0, BSD, LGPL, GPL

示例如下：

类注释

类注释应该要为读者提供使用该类的足够信息, 同时应当提醒读者在使用此类时要注意的事项。

示例如下：

函数注释

我们要在每个函数的声明处前加上注释, 描述该函数的功能和用途. 只有在函数的功能通俗易懂时才可以省略这些注释 (例如, 简单的取值和设值函数).。

示例如下：

变量注释

通常我们取变量名称的时候已经将其意义说明了。但是在逻辑复杂的情况下, 还是需要添加一些注释说明来做特别说明。

示例如下：

TODO 注释

对那些临时的, 短期的解决方案, 使用 TODO 注释。

示例如下：

弃用注释

通过注释（DEPRECATED comments）来标记接口已弃用，并要说明后续的替代方案。

示例如下：

最后

注释虽然写起来很痛苦, 但对保证代码可读性至关重要。 总而言之，学会写好代码注释，是每一个程序员的必备技术，也是一种良好的编程习惯，不仅仅是为了开发团队中的小伙伴，也是为了面对将来的自己。

参考资料：

1. https://zh-google-styleguide.readthedocs.io/en/latest/google-cpp-styleguide/comments/
2. https://bbs.huaweicloud.com/blogs/176194
3. https://github.com/onevcat/Kingfisher
4. https://github.com/Alamofire/Alamofire
5. https://www.zhihu.com/question/27246926/answer/1214585389

相关阅读：

Codable发布这么久我就不学，摸鱼爽歪歪，哎~就是玩儿

iOS 优雅的处理 络数据，你真的会吗如看看这篇

UICollectionView 自定义布局！看这篇就够了

Swift 探索 UICollectionView 之 SupplementaryView 和 Decoration View

UICollectionView 自定义布局实现瀑布流视图

使用 UICollectionView 实现分页滑动效果

使用 UICollectionView 实现首页卡片轮播效果

请你喝杯 ?? 点赞 + 关注哦～

1. 阅读完记得给我点个赞哦，有?? 有动力