shayne000的博客

1. 名副其实 变量、函数或类的名称应该已经答复了所有的大问题。它该告诉你，它为什么会存在，它做什么事，应该怎么用。如果名称需要注释来补充那就不算是名副其实。 2. 避免误导 程序员必须避免留下掩藏代码本意的错误线索。应当避免使用与本意相悖的词。例如，hp 、aix 和sco 都不该用做变量名，因为它们都是UNIX 平台或类UNIX 平台的专有名称。 别用accountList 来指称一组账号，除...

1. 短小 函数的第一规则是要短小。第二条规则是还要更短小。每个函数都只说一件事。而且，每个函数都依序把你带到下一个函数。这就是函数应该达到的短小程度! 代码块和缩进 if 语句、else 语句、while 语句等，其中的代码块应该只有一行。该行大抵应该是一个函数调用语句。这样不但能保持函数短小，而且，因为块内调用的函数拥有较具说明性的名称，从而增加了文档上的价值。 这也意味着函数不应该大到足以容...

1. 注释不能美化糟糕的代码 写注释的常见动机之一是糟糕的代码的存在。我们编写一个模块，发现它令人困扰、乱七八糟。我们知道，它烂透了。我们告诉自己：“喔，最好写点注释！”不！最好是把代码弄干净！ 带有少量注释的整洁而有表达力的代码，要比带有大量注释的零碎而复杂的代码像样得多。与其花时间编写解释你搞出的糟糕的代码的注释，不如花时间清洁那堆糟糕的代码。 2. 好注释 法律信息 提供信息的注释 对意图的...

1.函数 F1: 过多的参数 函数的参数量应该少。没参数最好，一个次之，两个、三个再次之。三个以上的参数非常值得质疑，应坚决避免。 F2: 输出参数 输出参数违反直觉。读者期望参数用于输入而非输出。如果函数非要修改什么东西的状态不可，就修改它所在对象的状态好了。 F3: 标识参数 布尔值参数大声宣告函数做了不止一件事。它们令人迷惑，应该消灭掉。 2.重复 每次看到重复代码，都代表遗漏了抽象。重复的...

1. 类的组织 类应该从一组变量列表开始。如果有公共静态常量，应该先出现。然后是私有静态变量，以及私有实体变量。很少会有公共变量。公共函数应跟在变量列表之后。 类应该短小 关于类的第一条规则是类应该短小。第二条规则是还要更短小 2.单一权责原则 单一权责原则(SRP) 认为，类或模块应该有且只有一条加以修改的理由。该原则既给出了权责的定义，又是关于类的长度的指导方针。类只应有一个权责一只有一条修改...