return 对代码可读性的影响
在函数中，是否应该控制尽量少的 `return` 出口？
比如 （以 `PHP` 代码举例）：
```
<?php

/**
 * 控制尽量少的退出点
 */
function foo1($var)
{
    try {
        if (empty($var)) {
            throw new \Exception('emty var');
        }

        if (!is_string($var)) {
            throw new \Exception('var must be string');
        }

        return sprintf("input-var:%s \n", $var);
    } catch (\Exception $e) {
        return sprintf("error:%s \n", $e->getMessage());
    }
}

/**
 * 不控制，可以结束的时候直接 return
 */
function foo2($var)
{
    if (empty($var)) {
        return 'error:empty var' . PHP_EOL;
    }

    if (!is_string($var)) {
        return 'error:var must be string' . PHP_EOL;
    }

    return sprintf("input-var:%s \n", $var);
}

```
### 常见观点
#### 正面：应该控制
- 过多的 `renturn`，增加了函数出口点，不利于代码阅读
#### 反面：没必要
- 多个 `return` 也没什么，类似 `try-catch` 在效率上有所损失，尽量少用
#### 中立
- 两种写法只是跟人风格问题，没有优略
- 短函数多个 `return` 无伤大雅，但是长函数中，会严重降低可读性
欢迎留下你的观点。
我的观点：
无论是短函数还是长函数，都尽量控制一下 `return` 点，因为短函数随着迭代可能会变成长函数。
而且多个 `return` 会明显降低长函数的可读性。
对于 `try-catch` 结构，在性能上的一丁点牺牲，换来的可读性提升，是值得的。
观点与你相反，函数中要尽可能多的使用 return 来控制，因为 return 从设计上来说就是这个功能，表示执行权限的移交。这样不会造成任何执行权限的问题。所谓函数，从设计之初，核心就是计算和返回。
滥用 try catch 会导致上级 try catch 无法正确捕获异常
语义化上来说，return 也比 try catch 更加清晰明了。