关于php:重新组织代码

代码该当易于了解

代码的写法该当使别人了解它所需的工夫最小化
本书链接: https://www.ituring.com.cn/bo…

把信息装进名字中

1. 清晰和准确比装可恶好;
2. 应用业余的词;
3. 应用具体的名字来更粗疏地形容事物;
4. 给变量名带上重要的细节;
5. 为作用域大的名字采纳更长的名字;
6. 有目的地应用大小写，下划线等;
7. 要多问本人几遍：“这个名字会被他人解读成其余的含意吗？”要认真扫视这个名字，不会被误会的名字是最好的名字;
8. 命名极限最分明的形式是在要限度的货色前加上 max_或者 min_;
9. 为布尔值命名时，防止应用反义的词（例如 disable_ssl）;
10. 要小心用户对特定词的冀望。例如，用户会冀望 get()或者 size()是轻量的办法;

审美

1. 统一的格调比“正确”的格调更重要;
2. 如果多个代码块做类似的事件，尝试让他们有同样的掠影;
3. 把代码按“列”对齐能够让代码更容易浏览;
4. 如果在一段代码中提到 A,B,C，那么不要在另一段中说 B,C,A，抉择一个有意义的秩序，并始终用这样的程序;
5. 用空行来把大块代码分成逻辑上的“段落”;

正文

1. 正文的目标是尽量帮忙读者理解的和作者一样多;

2. 什么中央不须要正文:

   • 能从代码自身中迅速地推断的事实;
   • 用来掩饰烂代码的“拐杖式正文”– 应该把代码改好;

3. 你该当记录下来的想法包含:

   • 对于为什么代码写成这样而不是那样的外在理由（“指导性批注”）;
   • 代码中的缺点，应用像 TODO: 或者 XXX: 这样的标记;
   • 常量背地的故事，为什么是这个值;

4. 站在读者的立场上思考:

   • 预料到代码中哪些局部会让读者说：“啊？”并且给他们加上正文;
   • 为一般读者意料之外的行为加上正文;
   • 在文件 / 类的级别上应用“全局观”正文来解释所有的局部是如何一起工作的;
   • 用正文来总结代码块，使读者不至于迷失在细节中;
5. 正文该当有很高的信息 / 空间率;
6. 尽量准确地形容函数的行为;
7. 在正文中用精心筛选的输出 / 输入例子进行阐明;
8. 申明代码的高层次用意，而非显著的细节;
9. 用含义丰富的词来使正文简洁;

控制流

1. 把条件，循环以及其余对控制流的扭转做的越“天然”越好，使用一种形式使读者不必停下来重读你的代码;
2. 绝对于谋求最小化代码行数，一个更好的度量办法是最小化人们了解它所需的工夫;
3. 当你对代码做改变时，从全新的角度扫视它，把它作为一个整体来对待;
4. 在写一个比拟时，把扭转的值写在右边并且把更稳固的值写在左边更好一些;
5. 你也能够重新排列 if/else 语句中的语句块，通常来讲，先解决正确的 / 简略的 / 乏味的状况;
6. 尽量不要用三目运算符;
7. 嵌套的代码块须要更加集中精力去了解，应该把它们改写成更加“线性”的代码来防止深浅套;
8. 通常来讲提前返回能够缩小嵌套并让代码整洁;

表达式

1. 把你的超长表达式拆分成更容易了解的小块;
2. 要小心“智能”的小代码块 – 它们往往在当前会让他人读起来感到困惑;

3. 引入“解释变量”来代表较长的子表达式，这种形式有三个益处:

   • 它把微小的表达式拆成小段;
   • 它通过用简略的名字形容子表达式来让代码文档化;
   • 它帮忙读者辨认代码中的次要概念;
4. 用德摩根定理来操作逻辑表达式 – 能够把布尔表达式用更整洁的形式重写（例如 if(!(a&&!b))变成 if(!a||b)）;
5. 有时须要把问题“反向”或者思考指标的对立面;

变量与可读性

1. 你心愿你的共事随时都感觉是在面试吗;
2. 让你的变量对尽量少的代码行可见;
3. 操作一个变量的中央越多，越难以确定它的以后值;
4. 缩小变量，即那些障碍的变量;
5. 减小变量的作用域，越小越好，把变量移到一个有起码代码能够看到它的中央，眼不见，心不烦;
6. 只写一次的变量更好，那些只设置一次值的变量（或者 const, final, 常量）使得代码更容易了解;

从新组织代码

1. 把个别代码和我的项目专有的代码离开;
2. 应该把代码组织得一次只做一件事件;
3. 把想法变成代码，用自然语言形容解决方案;
4. 最好的代码就是没有代码;
5. 删除没用的代码;
6. 从我的项目中打消不必要的性能，不要适度设计;
7. 重新考虑需要，解决版本最简略的问题，只有能实现工作就行;
8. 经常性地通读规范库的整个 API，放弃对他们的相熟水平 —“不要反复造轮子”;

测试

1. 测试也该当具备可读性，以便其余程序员能够难受地扭转或者减少测试;
2. 对使用者隐去不重要的细节，以便更重要的细节会更突出;
3. 让谬误音讯具备可读性;
4. 又简略又能实现工作的测试值更好;
5. 每个测试的最高一层应该越扼要越好，最好每个测试的输出 / 输入能够用一行代码来形容;
6. 如果测试失败了，它所收回的谬误音讯应该能让你容易跟踪并修改这个 bug;
7. 应用最简略的并且可能残缺使用代码的测试输出;
8. 给测试函数取一个有残缺描述性的名字，以使每个测试所测到的货色很明确，不要应用 test1()，而要应用 test_<functionName> 这样的名字;
9. 最重要的是，要使它易于改变和减少新的测试;