作者回复: 分享的经验质量非常高,nice。
关于pragma once,我的建议还是要慎用,因为很多时候我们还会导出纯C接口给外界,还是include guard最保险。
而且我记得在哪里看过资料,好像是cppreference上吧,pragma once也是有缺陷的。
作者回复:
1.可以多看看一些开源项目,它们的代码量比较大,你就可以体会到空格和空行的作用了。
专栏的GitHub仓库代码虽然比较小,但也都应用了这些规范,可以做参考。
2.说的很对,这也是注释一个非常重要的作用。我的建议是尽量不要删代码,毕竟是自己辛辛苦苦写出来的,删掉太可惜了。
应该用注释暂时禁用,放一段时间,如果确实没有用再考虑删除。
3.这个是include guard,后面的预处理阶段就会讲,你这是提前预习了,笑。
作者回复: 写的太好了,我非常感同身受。
作者回复: nice,用clang-format这样的工具能够减少很多手工的工作,但编码风格的意识还是要有的,不能完全依赖工具。
作者回复: 笑,看来我的隐身能力还是挺成功的。
作者回复: 对,这个几个对于改善代码可读性非常有用,而且也简单容易上手。
作者回复:
1.匈牙利命名法里的类型前缀现在已经不提倡了,比如你写了一个int iNum,后来想改成long,那么前缀i就失去意义了。m_和g_表示作用域还是很好的,不会因为重构而失效。
2.操作符两边加空格也是优良的编码风格传统了,留白非常重要。
作者回复: 看怎么用,如果是对外发布的,就写在声明,如果是内部用的,就在定义处。
但一定要注意,最好不要两处都有注释,否则一旦有变动,维护保持同步很麻烦。
作者回复: 那就只能“随大流”了,不过内心里还是要做一个“理想主义者”,笑。
作者回复: 记住代码是写给别人看的,自己看觉得很清楚,可别人不一定理解,所以适当的注释还是要有的。
最基本的文件头、函数和类的功能说明是必须的,关键的业务逻辑部分最好加上注释,每次有重大修改也应该加上注释说明。
作者回复:
1.注意,是成员变量加m_,成员函数不需要。
而且加m_也不是强制的,只是我个人的推荐,你一定要找到对自己最合适的风格。
2.其实真要全写各种注释也是很累的,看实际情况,在大中型项目中很有必要,小项目可以适当省略。
如果有code review,最好听一下别人的意见,看他们觉得哪里最需要注释。
作者回复: 有这个指标可以强制让大家多用空白,改善代码的可读性,具体的数字可以根据实际情况调整。
作者回复: 我是标准库、Boost、Nginx看习惯了,对于CamelCase总是不太适应。
作者回复: 共同营造“风清气正”的讨论氛围,笑。
作者回复: 说的很好。
作者回复:
1.函数参数的作用域仅限于本函数,作用域很小,而且在最前面,一眼就能看到,一般不用什么特别的前缀,但要注意不要写超长的函数。
2.如果你把变量类型改成vector<char>,那么前缀就失去意义了,所以尽量不要在名字里硬编码类型信息。
str前缀不应该表示具体类型,而是表示含义才对。
3.看习惯,还有公司的规范,没有强制标准。我个人喜欢用//。
作者回复: 这个完全就是个人的喜好了。
第一种写法我比较推荐,因为花括号的层次对应关系看得很清楚。
第二种写法比较紧凑,节约空间,因为Java流行它也就跟着流行了。
两种写法并无优劣之分,在项目里保持一致就好,有的工具也可以很简单地格式化,就不必为此纠结了。
作者回复: 自己写完注释后让旁边的同事看看,让别人指出有什么问题,该怎么写才好,多这样做就能写好注释了。
作者回复: 很对,但对于C++来说,并没有官方推荐的style,这大概也是C++崇尚的自由吧,我们可以任意选择自己喜欢的style。
作者回复: 好东西欢迎大家一起分享。