个人博客作业Week2

一、是否需要有代码规范

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

   
   我反驳这个观点,这些规范是成千上万的程序员在开发程序中总结出来的代码规范，他有助于我们的开发，也方便他人阅读我们的代码。即使在开发的过程中编码的速度会比你自己的规范要慢，但是从调试以及团队开发来看，这些规范能够大大提高程序的调试以及维护的效率，而且更加适合团队开发。

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

   
   我反驳这个观点，首先即使你是一个艺术家，手艺人，你能创造出一个属于自己的规范和原则，然而在成千上万的程序员面前你只是小小的一个，他们之间也会有更多的艺术家、手艺人，你自己一个人的见解必然比不上众人合起来的见解。而且在如今这个时代，开发程序都是团队开发，如果没有一个标准的代码规范，大家搜只是用自己的规范和原则，那么程序员之间的合作就会变得十分困难，开发的效率也会大大降低。而有了标准的规范，大家按照统一的代码规范来写代码，那么团队的开发效率就会有很大的提升。

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

   
   我支持这个观点，规范是死的，人是活的，在某些特殊的时候约定的规范不一定适用，这个时候就需要做一些灵活的变通以适应当前特定的场景，规范的作用在于能够让我们的开发更加有效率而不是一个强制的规定。但在绝大多数的情况下规范是适用的。

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

   
   我反驳这个观点，你说你擅长制定编码规范，那我可以说，大家都可以说自己擅长制定编码规范，凭什么要听你的呢？所以规范的制定不是某一个人说了算的，而是需要大家一起商量制定，集思广益才能够制定出更好的规范，才能适应于更多的开发者。

二、代码复审

General

• Does the code work? Does it perform its intended function, the logic is correct etc.

  
  这个代码能够正确运行，它能够执行生成四则运算题目和计算四则运算表达式，它的逻辑也是正确的。

• Is all the code easily understood?

  
  这个工程使用了C#语言，代码结构清晰，方法命名和变量命名都是有意义的命名，且代码中难点都有足够的注释，所以代码是易懂的。

• Does it conform to your agreed coding conventions? These will usually cover location of braces, variable and function names, line length,

  
  代码基本符合规定的编码约定，但是有一点不足的是部分代码一行过长，屏幕显示不下来，应该分成两行。

• s there any redundant or duplicate code?

  
  代码结构紧凑，几乎没有多余代码，且方法较多，一般使用地方比较多的代码都写成了函数，所以代码重复比较少。

• Is the code as modular as possible?

  
  代码定义了主类、数字类、表达式类和计算类，故代码是尽可能模块化。

• Can any global variables be replaced?

  
  代码没有全局变量，只有类属性，且都是私有的。

• Is there any commented out code?

  
  没有。

• Do loops have a set length and correct termination conditions?

  
  代码的循环有设定的长度和正确的终止条件。

• 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?

  
  几乎没有检查。

• Where third-party utilities are used, are returning errors being caught?

  
  没有使用第三方代码。

• Are output values checked and encoded?

  
  没有。

• Are invalid parameter values handled?

  
  没有。

Documentation

• Do comments exist and describe the intent of the code?

  
  有注释说明代码意图。

• Are all functions commented?

  
  几乎所有方法都有注释。

• Is any unusual behavior or edge-case handling described?

  
  没有描述。

• Is the use and function of third-party libraries documented?

  
  未使用第三方代码。

• Are data structures and units of measurement explained?

  
  解释了。

• 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?

  
  是。

• Are arrays checked for ‘out-of-bound’ errors?

  
  未检查。

• Could any test code be replaced with the use of an existing API?

  
  不存在现有的API能取代测试代码。