PHP 開発者のためのプログラミング ガイド パート 1: 複雑さの軽減、開発者のためのプログラミング ガイド_PHP チュートリアル

PHP 開発者のためのプログラミング ガイド パート 1: 複雑さの軽減、開発者のためのプログラミング ガイド

PHP は自由度の高いプログラミング言語です。これは動的言語であり、プログラマに対して非常に寛容です。 PHP プログラマーは、コードをより効率的にするために多くの仕様を理解する必要があります。長年にわたって、私は多くのプログラミング本を読み、コーディング スタイルの問題について多くの上級プログラマーと議論してきました。どのルールがどの本や人から引用されたのかはきっと覚えていないでしょうが、この記事 (および今後の別の記事) は、より良いコードを書く方法についての私の見解を述べています。コードは通常、テストに耐えることができます。読みやすく、理解できる。このようなコードを使用すると、他の人が問題を見つけやすくなり、コードを再利用しやすくなります。
関数本体の複雑さを軽減する

メソッドまたは関数本体では、複雑さを可能な限り軽減します。複雑さが比較的低いため、他の人がコードを読みやすくなります。さらに、これを行うと、コードに問題が発生する可能性が減り、問題が発生した場合の修正や修正が容易になります。
関数内の括弧の数を減らす

if、elseif、else、switch ステートメントはできるだけ使用しないでください。さらに括弧が追加されます。これにより、コードがより理解しやすくなり、テストが難しくなります (各ブラケットをテスト ケースでカバーする必要があるため)。この問題を回避する方法は常にあります。
エージェントの意思決定 (「聞かずに伝えてください」)
場合によっては、わかりやすくするために if ステートメントを別のオブジェクトに移動することができます。例:

次のように変更できます:
                                                                                                                                          ここでは、$a オブジェクトの doSomething() メソッドによって具体的な判断を行っています。これについてはこれ以上考える必要はありません。単に doSomething() を安全に呼び出す必要があるだけです。このアプローチは、コマンドではなくクエリを実行するという原則に従っています。この原則を詳しく見てみることをお勧めします。この原則は、オブジェクトに情報をクエリし、その情報に基づいて判断するときにいつでも適用できます。 地図を使用する
場合によっては、map ステートメントを使用して、if、elseif、または else の使用を減らすことができます。例: リーリー
は次のように簡略化できます: リーリー

強制型

多くの if ステートメントは、型をより厳密に使用することで回避できます。例:

リーリー
$a にタイプ A を強制的に使用することで簡略化できます: リーリー

早く帰ってください

多くの場合、関数内の分岐は実際の分岐ではなく、次のような事前条件または事後条件です。 // Preconditions

リーリー
ここでの if ステートメントは関数実行の分岐ではなく、単なる前提条件のチェックです。場合によっては、PHP 自体に前提条件チェックを行わせることができます (適切な型ヒントの使用など)。ただし、PHP はすべての前提条件チェックを完了できるわけではないため、一部の前提条件チェックをコード内に残しておく必要があります。複雑さを軽減するには、コードが間違っていることが事前にわかっている場合、入力が間違っている場合、および結果がすでにわかっている場合に、できるだけ早く戻る必要があります。 できるだけ早く返すことの効果は、後続のコードを以前のようにインデントする必要がなくなることです:

上記のテンプレートと同様に、コードはより読みやすく、理解しやすいように変更されます。

如果函数体过长，就很难理解这个函数到底在干什么。跟踪变量的使用、变量类型、变量声明周期、调用的辅助函数等等，这些都会消耗很多脑细胞。如果函数比较小，对于理解函数功能很有帮助（例如，函数只是接受一些输入，做一些处理，再返回结果）。
使用辅助函数
在使用之前的原则减少括号之后，你还可以通过把函数拆分成更小的逻辑单元做到让函数更清晰。你可以把实现一个子任务的代码行看做一组代码，这些代码组直接用空行来分隔。然后考虑如何把它们拆分成辅助方法（即重构中的提炼方法）。
辅助方法一般是 private 的方法，只会被所属的特定类的对象调用。通常它们不需要访问实例的变量，这种情况需要定义为 static 的方法。在我的经验中，private (static)的辅助方法通常会汇总到分离的类中，并且定义成 public (static 或 instance)的方法，至少在测试驱动开发的时候使用一个协作类就是这种情形。
减少临时变量
长的函数通常需要一些变量来保存中间结果。这些临时变量跟踪起来比较麻烦：你需要记住它们是否已经初始化了，是否还有用，现在的值又是多少等等。
上节提到的辅助函数有助于减少临时变量：

public function capitalizeAndReverse(array $names) {
  $capitalized = array_map('ucfirst', $names);
  $capitalizedAndReversed = array_map('strrev', $capitalized);
  return $capitalizedAndReversed;
}

使用辅助方法，我们可以不用临时变量了：

public function capitalizeAndReverse(array $names) {
  return self::reverse(
    self::capitalize($names)
  );
}
 
private static function reverse(array $names) {
  return array_map('strrev', $names);
}
 
private static function capitalize(array $names) {
  return array_map('ucfirst', $names);
}

正如你所见，我们把函数变成新函数的组合，这样变得更易懂，也更容易修改。某种方式上，代码还有点符合“扩展开放/修改关闭”，因为我们基本上不需要再修改辅助函数。
由于很多算法需要遍历容器，从而得到新的容器或者计算出一个结果，此时把容器本身当做一个“一等公民”并且附加上相关的行为，这样做是很有意义的：

classNames
{
  private $names;
 
  public function __construct(array $names)
  {
    $this->names = $names;
  }
 
  public function reverse()
  {
    return new self(
      array_map('strrev', $names)
    );
  }
 
  public function capitalize()
  {
    return new self(
      array_map('ucfirst', $names)
    );
  }
}
$result = (newNames([...]))->capitalize()->reverse();

这样做可以简化函数的组合。
虽然减少临时变量通常会带来好的设计，不过上面的例子中也没必要干掉所有的临时变量。有时候临时变量的用处是很清晰的，作用也是一目了然的，就没必要精简。

使用简单的类型

追踪变量的当前取值总是很麻烦的，当不清楚变量的类型时尤其如此。而如果一个变量的类型不是固定的，那简直就是噩梦。
数组只包含同一种类型的值
使用数组作为可遍历的容器时，不管什么情况都要确保只使用同一种类型的值。这可以降低遍历数组读取数据的循环的复杂度：

foreach($collection as $value) {
  // 如果指定$value的类型，就不需要做类型检查
}

你的代码编辑器也会为你提供数组值的类型提示：

/**
 * @param DateTime[] $collection
 */
public function doSomething(array $collection) {
  foreach($collection as $value) {
    // $value是DateTime类型
  }
}

而如果你不能确定 $value 是 DateTime 类型的话，你就不得不在函数里添加前置判断来检查其类型。beberlei/assert库可以让这个事情简单一些：

useAssert\Assertion
 
public function doSomething(array $collection) {
  Assertion::allIsInstanceOf($collection, \DateTime::class);
 
  ...
}

如果容器里有内容不是 DateTime 类型，这会抛出一个 InvalidArgumentException 异常。除了强制输入相同类型的值之外，使用断言（assert）也是降低代码复杂度的一种手段，因为你可以不在函数的头部去做类型的检查。
简单的返回值类型
只要函数的返回值可能有不同的类型，就会极大的增加调用端代码的复杂度：

$result= someFunction();
if($result=== false) {
  ...
}else if(is_int($result)) {
  ...
}

PHP 并不能阻止你返回不同类型的值（或者使用不同类型的参数）。但是这样做只会造成大量的混乱，你的程序里也会到处都充斥着 if 语句。
下面是一个经常遇到的返回混合类型的例子：

/**
 * @param int $id
 * @return User|null
 */
public function findById($id)
{
  ...
}

这个函数会返回 User 对象或者 null，这种做法是有问题的，如果不检查返回值是否合法的 User 对象，我们是不能去调用返回值的方法的。在 PHP 7之前，这样做会造成"Fatal error"，然后程序崩溃。
下一篇文章我们会考虑 null，告诉你如何去处理它们。
可读的表达式

我们已经讨论过不少降低函数的整体复杂度的方法。在更细粒度上我们也可以做一些事情来减少代码的复杂度。
隐藏复杂的逻辑

通常可以把复杂的表达式变成辅助函数。看看下面的代码：

if(($a||$b) &&$c) {
  ...
}

可以变得更简单一些，像这样：

if(somethingIsTheCase($a,$b,$c)) {
  ...
}

阅读代码时可以清楚的知道这个判断依赖 $a, $b 和 $c 三个变量，而函数名也可以很好的表达判断条件的内容。
使用布尔表达式
if 表达式的内容可以转换成布尔表达式。不过 PHP 也没有强制你必须提供 boolean 值：

$a=new\DateTime();
...
 
if($a) {
  ...
}

$a 会自动转换成 boolean 类型。强制类型转换是 bug 的主要来源之一，不过还有一个问题是会对代码的理解带来复杂性，因为这里的类型转换是隐式的。PHP 的隐式转换的替代方案是显式的进行类型转换，例如：

if($a instanceof DateTime) {
  ...
}

如果你知道比较的是 bool 类型，就可以简化成这样：

if($b=== false) {
  ...
}

使用 ! 操作符则还可以简化：

if(!$b) {
  ...
}

不要 Yoda 风格的表达式
Yoda 风格的表达式就像这样：

if('hello'===$result) {
  ...
}

这种表达式主要是为了避免下面的错误：

if($result='hello') {
  ...
}

这里 'hello' 会赋值给 $result，然后成为整个表达式的值。'hello' 会自动转换成 bool 类型，这里会转换成 true。于是 if 分支里的代码在这里会总是被执行。
使用 Yoda 风格的表达式可以帮你避免这类问题：

if('hello'=$result) {
  ...
}

我觉得实际情况下不太会有人出现这种错误，除非他还在学习 PHP 的基本语法。而且，Yoda 风格的代码也有不小的代价：可读性。这样的表达式不太易读，也不太容易懂，因为这不符合自然语言的习惯。

以上就是本文的全部内容，希望对大家的学习有所帮助。

您可能感兴趣的文章:

• php和js编程中的延迟执行效果的代码
• PHP编程过程中需要了解的this,self,parent的区别
• 《PHP编程最快明白》第四讲：日期、表单接收、session、cookie
• 《PHP编程最快明白》第六讲：Mysql数据库操作
• php学习笔记之面向对象编程
• 深入php之规范编程命名小结
• PHP编程风格规范分享
• php使用socket编程示例
• PHP多进程编程实例