clean code 之代码格式

我们应该保持良好的代码格式，选用一套管理代码格式的简单规则，然后贯彻这些规则

 

1,格式的目的

 

格式的目地在于沟通，所以代码格式很重要，且不可忽略

 

2,向报纸学习

 

我们看看写的很好的报纸是什么样的，首先，有个头条，告诉我们故事的主题，第一段是故事的大纲，接着读下去，细节读逐渐增加，直至了解所有的东西

 

源文件也要向报纸文章那样，名称简单一目了然，细节应往下一依次展开，直至找到源文件中最底层的函数和细节

 

3,概念间垂直方向的的区隔

 

在封包声明，导入声明和每个函数之间，都有空白行隔开，这条简单的规则将极大的影响到代码的视觉外观，每个空白行都是一条线索，表示出新的独立概念

 

//这里展现了空白行区的作用
package fitnesse wikitext,widgets;

inport java.util.regex.*;

  public class BoldWidgets extends ParentWidget {
    public static final String REGEXP = " '''. + ?''' ";
    private static final Pattern pattern = pattern.compile(" '''(.+?)''' ",
      pattern.MULTILINE + pattern.DOTALL
  );

  public BoldWidget (ParentWidget parent,String text) Throws Expection {
    super(parent);
    Matcher match = pattern.matcher(text);
    match.find();
    addChildWidgets(match.group(1));
  }
}//若抽掉那些空白行，代码的可读性将会减弱不少

其实，空白行区的作用还可以表示代码的关联——靠近的代码行暗示了它们的紧密的关系

 

4,变量的声明

 

a，变量的声明应尽可能的靠近其使用位置

b，概念相关的代码应该放在一起，相关性越强，彼此之间的距离就该越短

c，相关函数应放在一起

d，全局变量应该放在顶端

 

function add_item_to_transfer(inputs)
{
    var transfer = [];
    var item = loadAllItems();
    for(var i = 0; i < inputs.length; i ++)
    {
        compare_barcode(item,i,inputs,transfer);
    }
    return(transfer);
}
function compare_item_and_inputs_barcode(item,i,inputs,transfer)
{
    for(var j = 0; j < item.length; j ++)
    {
        compare_same_barcode(item,inputs,i,j,transfer);
    }
}

 

5,横向格式

 

一行代码应该有多宽？

 

我们应尽力保持代码行短小，随着显示器越来越宽，屏幕上甚至可以容纳200个字符，我们不必僵化的死守80个字符上线的规则，但再多并无好处，个人建议120个字符

 

6,对齐

 

空格字符：加强分隔效果，强调前面的运算符。

 

public class FitnesseExpediter implements ResponseSender
{
  private         Socket              socket;
  private         InputStream     input;
  protected     long                  requestParsingTimeLimit;
}//我们经常使用水平对齐来强调某些程序结构,但实际上，对齐，像是在强调某些不重要的东西，而把读者的目光从从真正的意义上拉开
//更麻烦的是，代码自动化格式工具会将这类对齐消除掉

  

 

而不对齐的的声明和赋值，其实恰恰指明了重点

 

7,缩进

 

for(vari=0;i<inputs.length;i++){for(varj=0;j<item.length;j++){if(inputs[i]=item[j].barcode){inputs[i].count=1}}}//没有缩进的话，程序会变的非常难以阅读

 

8,团队规则

 

每个程序员都有自己喜欢的代码规则，但如果在同一个团队中工作，就是团队说了算，我们想要让软件拥有一以贯之的风格，而不是让它显得是由一大票意见相左的个人写成，绝对不要用各种不同风格来编写源代码