个人博客作业2--代码规范和代码复审

1.是否要有代码规范

　　首先，我对于这个问题本身来回答我的看法，代码规范是一定要有的，规范本身就是人们在重复进行类似工作的时候形成的常识性行为，哪怕你没有可以按照某些规范进行，一点一点也一定会形成自己的习惯和规范，所以是否要有代码规范这个问题本身是没有疑问的，有规范本身就是一个规范..

　　接下来结合以下论点来谈论我的观点：

　　“1.这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。”

　　我觉得说这种话的人不是有病就是当时说话没走脑，什么都往官僚制度上靠？看了资料，这句话还是一个一个后来有权限查看谷歌代码库的一个资深程序员，也许是他之前太年轻了，他真的知道什么叫官僚制度吗？影响效率？浪费时间？管理者有必要这样么？都巴不得你效率超高，高能高产。就算是官僚定规范也是要对官僚自己有好处的好么？规范有问题可以修改，但规范存在的本身绝对是为了提高效率，节省时间的。

　　“2.我是个艺术家，手艺人，我有自己的规范和原则。”

　　说实话，如果真的有艺术细胞的话，我还是很欣赏的，比如说混乱代码大赛，这样的人我觉得还是很厉害的。但这只是特定场合的需求罢了。如果是某某工程中的某某说出这样的话，那还真是图样了，你应该追求的艺术不应该被规范所局限，真正的艺术应该是巧妙的创新，新奇的思想，这些东西在有统一规范的推动下，别人更加能够看清你的创造力。不过，如果你能够制定出既有艺术感又能够提高效率同时具有较好可读性的规范的话，那也是极好的。管理者也一定会鼓励员工参与规范的制定的，毕竟只有亲自参与进来才能真正知道什么样的规范才是好的。

　　“3.规范不能强求一律，应该允许很多例外”

　　这点我还是稍微有点赞同的，是稍微有点，我赞同的部分是有例外，但是这个“很多”是绝对不可以的，很多例外的话那还叫规范了么...但是完全不允许例外的产生我觉得也是有点太过苛刻，规范也应当稍微有一些弹性，比如整个大项目有个统一的规范，然后你所在的特定的小项目里可以扩展特定的规范以适应特定的需求来提升质量。

　　“4.我擅长制定编码规范，你们听我的就好了”

　　这话听起来就像是大话，真正擅长的话肯定是有极其多的经验，而且还了解大部分员工编程的风格和喜好，擅长也是需要有极其多的基础的。如果能够真正给大家带来效率和质量的提升，那么我想大家还是很愿意听从的。不过如果这个只是大话空话的话，那么我赵日天第一个不服....

 

 

2.代码复审

　　General

• Does the code work? Does it perform its intended function, the logic is correct etc.
  • Yes
• Is all the code easily understood?
  • Yes
• Does it conform to your agreed coding conventions? These will usually cover location of braces, variable and function names, line length, indentations, formatting, and comments.
  • 除了大括号换行和函数名和变量名都用拼音我的习惯不同之外，别的都大概符合
• Is there any redundant or duplicate code?
  • 有些相同的代码段可以写成函数替代
• Is the code as modular as possible?
  • main函数还是有太多出命令行参数之外的功能部分，模块化还可以增强。
• Can any global variables be replaced?
  • 没有全局变量..
• Is there any commented out code?
  • No
• Do loops have a set length and correct termination conditions?
  • Yes
• Can any of the code be replaced with library functions?
  • 大概没有现成的库可以替代..
• Can any logging or debugging code be removed?
  • 可以.

　　Security

• Are all data inputs checked (for the correct type, length, format, and range) and encoded?
  • Yes
• Where third-party utilities are used, are returning errors being caught?
  • 没涉及到第三方工具使用..
• Are output values checked and encoded?
  • Yes
• Are invalid parameter values handled?
  • Yes

　　Documentation

• Do comments exist and describe the intent of the code?
  • Yes
• Are all functions commented?
  • No
• Is any unusual behavior or edge-case handling described?
  • No
• Is the use and function of third-party libraries documented?
  • No
• Are data structures and units of measurement explained?
  • Yes
• Is there any incomplete code? If so, should it be removed or flagged with a suitable marker like ‘TODO’?
  
  • 没有

　　Testing

• Is the code testable? i.e. don’t add too many or hide dependencies, unable to initialize objects, test frameworks can use methods etc.
  • 可测试
• Do tests exist and are they comprehensive? i.e. has at least your agreed on code coverage.
  • 还算比较全面.
• Do unit tests actually test that the code is performing the intended functionality?
  • Yes
• Are arrays checked for ‘out-of-bound’ errors?
  • 检查了数组越界的errors
• Could any test code be replaced with the use of an existing API?
  • 没有什么existing的API，不知道能不能替代