yeshu blog
0%

代码规范笔记

Posted on

只记录一些自己接触过的或思考过的点

  • 每次只声明一个变量

      不要使用组合声明，比如int a, b;。

  • default的情况要写出来

     每个switch语句都包含一个default语句组，即使它什么代码也不包含。

  • 量词列表：量词后缀说明

      First,Last,Next,Prev,Cur,List,Map,Set,Arr

  • 动画命名例子 规范写法

      fade_in	淡入
  fade_out	淡出
  push_down_in	从下方推入
  push_down_out	从下方推出
  push_left	推向左方
  slide_in_from_top	从头部滑动进入
  zoom_enter	变形进入
  slide_in	滑动进入
  shrink_to_middle	中间缩小

  • 捕获的异常：不能忽视

      除了下面的例子，对捕获的异常不做响应是极少正确的。(典型的响应方式是打印日志，或者如果它被认为是不可能的，则把它当作一个 AssertionError 重新抛出。)
如果它确实是不需要在catch块中做任何响应，需要做注释加以说明(如下面的例子)。

try {
    int i = Integer.parseInt(response);
    return handleNumericResponse();
} catch (NumberFormatException ok) {
    // it's not numeric; that's fine, just continue
}
return handleTextResponse(response);
  • 避免使用全局变量和类成员（class member）来传递信息（会让函数不在具有明确的输入输出特性）
class A {
    String x;

    void findX() {
       ...
       x = ...;
    }

    void foo() {
      findX();
      ...
      print(x);
    }
  }

写成

String findX() {
   ...
   x = ...;
   return x;
}
void foo() {
  int x = findX();
  print(x);
}

  • 使用有意义的函数和变量名字（变量的生命应当放在理她使用最近的地方）

  • 不要重用局部变量

  • 把复杂的表达式提取出去，做成中间变量

  • 写模块化的代码

      有些人吵着闹着要让程序“模块化”，结果他们的做法是把代码分部到多个文件和目录里面，然后把这些目录或者文件叫做“module”。他们甚至把这些目录分放在不同的 VCS repo 里面。结果这样的作法并没有带来合作的流畅，而是带来了许多的麻烦。这是因为他们其实并不理解什么叫做“模块”，肤浅的把代码切割开来，分放在不同的位置，其实非但不能达到模块化的目的，而且制造了不必要的麻烦。
  方法：
  1. 避免写太长的函数
  2. 制造小的工具函数
  3. 每个函数只做一件简单的事情

  有些人喜欢制造一些“通用”的函数，既可以做这个又可以做那个，它的内部依据某些变量和条件，来“选择”这个函数所要做的事情。

  • 避免使用全局变量和类成员（class member）来传递信息（会让函数不在具有明确的输入输出特性）

  • 不要把null放进“容器数据结构”里面

      函数调用者：明确理解null所表示的意义，尽早检查和处理null返回值，减少它的传播

  函数作者：明确声明不接受null参数，当参数是null时立即崩溃。
  不要试图对null进行“容错”，不要让程序继续往下执行。如果调用者使用了null作为参数，那么调用者（而不是函数作者）应该对程序的崩溃负全责。
  （就在于人们对于null的“容忍态度”。这种“保护式”的写法，试图“容错”，试图“优雅的处理null”，其结果是让调用者更加肆无忌惮的传递null给你的函数。）
  （容错这种保护式写法，最终会让调用者写代码毫无忌惮，将错误因子导出传递，造成很难排查错误和代码逻辑混乱）

    正确做法：

public static <T> T requireNonNull(T obj) {
  if (obj == null) {
    throw new NullPointerException();
  } else {
    return obj;
  }
}

  • 防止过度设计

      另外一种过度工程的来源，是过度的关心“代码重用”。很多人“可用”的代码还没写出来呢，就在关心“重用”。为了让代码可以重用，最后被自己搞出来的各种框架捆住手脚，最后连可用的代码就没写好。如果可用的代码都写不好，又何谈重用呢？
  
  根据这些，我总结出来的防止过度工程的原则如下：
  1. 先把眼前的问题解决掉，解决好，再考虑将来的扩展问题。
  2. 先写出可用的代码，反复推敲，再考虑是否需要重用的问题。
  3. 先写出可用，简单，明显没有bug的代码，再考虑测试的问题。

资料来源和更多