02 | 编码阶段能做什么：秀出好的code style
该思维导图由 AI 生成，仅供参考
空格与空行
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文从代码格式、标识符命名和注释三个方面详细介绍了如何展现出良好的代码风格。首先，强调了合理运用空格和空行，使代码错落有致，易于理解。其次，提出了混用“匈牙利命名法”、“CamelCase”和“snake_case”的建议，并给出了具体的命名规则示例。此外，强调了变量/函数名字长度与作用域成正比的原则。在注释方面，强调了注释的正确、清晰、有效，以及使用英文写注释的重要性。此外，建议在文件的开头写上文件的注释，包括版权声明、更新历史、功能描述等。最后，强调了良好的编程习惯和态度的重要性，并提出了课下作业的思考题。总的来说，本文为读者提供了编写清晰易读代码的指导，使读者能够在编码阶段展现出良好的code style。
《罗剑锋的 C++ 实战笔记》，新⼈⾸单¥59
全部留言(51)
- 最新
- 精选
嵇斌分享我的一些实践： 1. 匈牙利命名真心不推荐了，参考《clean code》中关于avoid encoding的说明。 2. 如果是存现代c++工程，不考虑兼容C的话. Header guards可以使用#pragma once替代。 3. 避免注释，最好使用代码来阐述。很多信息可以通过代码仓库来表达，比如commit message。 4. m_，g_ 等前缀如果使用现代化的ide的话，也可以考虑省略，因为ide的高亮能够区分。 5. 如果不是在写类库，比如开发应用程序，最好命名规则能快速区分这个是你的代码，还是标准库、知名类库的代码，可能这也是大厂流行CamalCase的缘由。 6. Google的style guide是个不错的参考，但是也有很多不可取的规则，感觉原因：Google出这个guide的时候modern c++还没有流行，Google当时内部还有很多技术债，Google想把c++写的像java。所以Google后来在golang里面.... 7. 如果是参与现有项目，无论现有规则多么的不爽，都先遵循现有的规则。作者回复: 分享的经验质量非常高，nice。 关于pragma once，我的建议还是要慎用，因为很多时候我们还会导出纯C接口给外界，还是include guard最保险。 而且我记得在哪里看过资料，好像是cppreference上吧，pragma once也是有缺陷的。
2020-05-09337
jxon-H磨刀不误砍柴工，编码风格我觉得不仅是软件开发行业的共识，更是一种软件开发的文化。回顾我自己写过的代码，简直惨不忍睹。罗老师这节内容让我收获极大，也让进一步加深了以下认识： 1、之所以讲究编码风格，因为软件的规模越大，协作性要求就越高，软件开发是一件群体性的智力活动，每个人的代码都只有自己懂，每段代码都将成为一个信息孤岛，没法让代码变得可交流、可复用、可维护。 2、一段代码的功能，不仅仅是完成一个任务，也是一种思想的传播，因此注释担当着传递信息的功能，要养成良好的注释习惯和明了易懂注释风格。 3、留白的艺术深受启发，既给代码空间留下了闲余，给视觉留下了美感，也给代码的阅读增添了节奏，更是给大脑腾出足够的思考空间。作者回复: 写的太好了，我非常感同身受。
2020-05-0916
Carlos哈哈, 容我先说一句题外话, 我作为一个 c++ 入门新手, 昨天和前天还真的读了一份 "公司色彩很重" 的 code style guide 😂(虽然没完全读懂). 1. 今天文章中的 "留白", 和 "命名" 我倒是注意到了, 但是可能因为我目前写的 c++ 代码基本上都是不超过 50 行的练习文件, 所以注释这一点我没有注意到, 从现在开始注意. 2. 我觉得另一个重要的用法是把一些代码备注掉. 可能是为了 debug 方便(如果新代码错了, 换回旧代码, 程序还能运行), 也可能是为了以后功能拓展方便(直接把相关模块取消备注就能用了). 补充一条我前天刚学会的 code style: All header files should have #define guards to prevent multiple inclusion. The format of the symbol name should be <PROJECT>_<PATH>_<FILE>_H_作者回复: 1.可以多看看一些开源项目，它们的代码量比较大，你就可以体会到空格和空行的作用了。 专栏的GitHub仓库代码虽然比较小，但也都应用了这些规范，可以做参考。 2.说的很对，这也是注释一个非常重要的作用。我的建议是尽量不要删代码，毕竟是自己辛辛苦苦写出来的，删掉太可惜了。 应该用注释暂时禁用，放一段时间，如果确实没有用再考虑删除。 3.这个是include guard，后面的预处理阶段就会讲，你这是提前预习了，笑。
2020-05-09315
winsummer老师，函数的注释是写在声明处还是写在定义处好呢作者回复: 看怎么用，如果是对外发布的，就写在声明，如果是内部用的，就在定义处。 但一定要注意，最好不要两处都有注释，否则一旦有变动，维护保持同步很麻烦。
2020-05-0911- Yaxe昨天上github看cpp_study这个仓库的时候 发现头像莫名熟悉，才知道之前star的注释版nginx也是罗大写的 十分有缘 学习学习！
作者回复: 笑，看来我的隐身能力还是挺成功的。
2020-05-097 
幻境之桥在此基础上使用 clang-format 统一并减少大部分手工格式化的工作作者回复: nice，用clang-format这样的工具能够减少很多手工的工作，但编码风格的意识还是要有的，不能完全依赖工具。
2020-05-096
湫兮如风看完一节的内容一定一定要阅读大家的评论！罗老师这个专栏的氛围真好、质量真高!师生共进!作者回复: 共同营造“风清气正”的讨论氛围，笑。
2020-07-0125- Geek_0315ca我比较喜欢变量名使用m和g前缀，说明变量的作用域范围；todo注释标注自己未实现的功能和想法💡 ；函数体内部使用空行分离不同的代码片段
作者回复: 对，这个几个对于改善代码可读性非常有用，而且也简单容易上手。
2020-05-095 
yelin特别喜欢匈牙利命名法里的类型前缀，不过现在使用的也基本就是m和g前缀了。我个人特别喜欢空格！很多CPP check，没有空格是会报错的，所以不能说习惯啦，这是规则。作者回复: 1.匈牙利命名法里的类型前缀现在已经不提倡了，比如你写了一个int iNum，后来想改成long，那么前缀i就失去意义了。m_和g_表示作用域还是很好的，不会因为重构而失效。 2.操作符两边加空格也是优良的编码风格传统了，留白非常重要。
2020-05-134
hb其实各个语言都有自己的code style， 例如OC就是习惯驼峰命名，基本不用加 "_"作者回复: 很对，但对于C++来说，并没有官方推荐的style，这大概也是C++崇尚的自由吧，我们可以任意选择自己喜欢的style。
2020-05-114
