Tokyo_2024的博客

只规定需要规定的事情：不要强制施加个人喜好或者过时的做法；1.    有些问题只是个人喜好，并不影响程序的正确性或者可读性，所以这些问题不应该出现在编程规范中；2.    应该在每个源文件乃至每个项目中都使用一致的格式，因为同一段代码中要在几种编程风格之间换来换去是非常不舒服的；3.    常见不应该标准化的东西：(1)  不要规定缩进多少，应该规定要用缩进来体现代码的结构；(2)  不要强制行的...

高度重视警告：使用编译器的最高警告级别；因该要求构建是干净利落的（没有警告）；理解所有警告。通过修改代码而不是降低警告级别来排除警告；1.    编译器是你的朋友，如果它对某个构造发出警告，这经常说明你的代码中存在潜在问题；2.    排除警告的正确做法：(1)  把它弄清楚；(2)  改写代码以排除警告，并使代码阅读者和编译器都能更加清楚，代码是按照编写者意图执行的；3.    即使程序一开始似...

       一次按键就解决问题：使用完全自动化(单操作)的构建系统，无需用户干预即可构建整个项目；1.    我们都不应该将时间和精力浪费在机器可以干得更快，更好的事情上；自动的，可靠的，单操作的构建是非常有必要的；2.    成功的构建应该无声无息，不产生任何警告；理想的构建过程不会出现噪声，只会出现一条日志信息：构建成功；3.    构建有两种模式：增量构建(重新构建上次发生改变的部分)和完...

好记性不如烂笔头：请使用版本控制系统(VCS)，永远不要让文件长时间地登出；在新的测试单元通过之后，应该频繁登入。确保登入的代码不会影响成功； 1.    几乎大一点的项目都需要一个以上的开发人员和(或)一周以上的开发时间；在这样的项目中，将需要比较同一文件的各个历史版本，以确定修改是何时(以及/或者由谁)进行的，需要控制和管理源代码的变更；2.    如果有多个开发人员，他们将会并行地进行修改，...

       审查代码：更多的关注有助于提高质量；亮出自己的代码，阅读别人的代码；相互学习，彼此都会受益； 1.    好的代码审查过程对开发团队有很多方面的益处：(1)  通过来自同伴的良性压力提高代码质量；(2)  找出错误，不可移植的代码(如果适用)和潜在的扩展问题；(3)  通过交流思想获得更好的设计和实现；(4)  快速培养新同事和初入门着；(5)  在团队中形成共同的价值观和集体主义；...

编码风格1. 命名规则:类名         大写C开头，其后每个单词首字母大写，单词之间不加任何分隔符                                     CRenderComponent结构名 大写S开头，其余规则同类名 SRectangle枚举名 大写E开头，其余规则同类名 ENodeType类的公有函数 第一个单词首字母小写，且必须为动词，其后每个单词首字母大写，单词之...

1.    注释不一定能提高函数的可读性和可维护性；(1)  很多人在修改代码的时候，注意力都放在代码，功能上，修改代码之后忙着马上编译运行；只要功能和预期的一致就觉得可以了，置于与代码匹配的注释，往往会忘记同步修改；(2)  一旦注释与代码不一致，以后维护该代码的程序员就会非常困惑，不知道应该相信注释还是该相信注释；(3)  解决办法：解决问题的办法是不用注释，让代码本身来解释代码的功能；例如将...