尽可能延后变量定义式的出现时间

本条例是为了节约开销，提升效率而设置的。我们在学习的过程中，或多或少看到过先定义再赋值的代码，比如下面这样

这种写法不会引起错误，但是可能会导致效率下降，比如定义了不会使用的变量，这样的话我们要承担这个变量的构建和析构的开销，浪费了 CPU 的周期。比如下面这样

我们承担了两个 int 和 一个 string 的创建和释放的开销，但是没起到丝毫作用（现代编译器可能会将这样的代码优化，将没有影响最终结果的变量和计算过程都有化掉，但是我们不能依靠编译器，得规范自己）。

有的时候不一定是我们故意定义没用的变量，而是程序在运行过程中出现异常，导致白白创建而没使用就结束了。比如下面这样

可能 encrypted 刚被创建，遇到异常，然后 throw 吐出异常，导致 string 创建毫无意义反而降低了CPU执行效率。

优化之后，可能你会想到是这样

其实这个还不够，因为这里的 encrypted 的创建还不够延后，这里的 encrypted 创建是使用默认构造函数，后面的代码肯定还有赋值操作，也就是使用了一次默认构造，一次赋值操作。如果我在创建其的时候就使用拷贝构造，那么效率会更高，也就是在时间上 一次默认构造+一次赋值操作 > 一次拷贝构造。

这样就会更好。

然后可能还有一种情况，就是面对循环，变量究竟在循环内定义还是循环外呢？

假设 type 是一个 class，对于 case 1，开销是一个构造函数、一个析构函数、n个赋值操作，对于case 2，开销是n个构造函数、n个析构函数。case 1 大体来说效率要更高，尤其当 n 很大的时候，如果n很小，case 2 更好。case 1 可能会带来意外，因为 case 1 的 t 作用域更大，在 for 循环之后的代码有误操作的可能。因此对于 1 和 2 的选择应该考虑以下情况：

1. 你知道 赋值 成本 小于 析构 + 构造

2. 你正在处理代码中效率很敏感的部分

如果属于上述两种，选择 case 1，否则选择 case 2.