关于程序的边界检查

编写程序时应该怎样对待边界条件的检查？
[理想的程序应该是布局精巧，简洁，优雅的，那些多余的边界条件的存在简直显得有些可耻。不必要的边界检查是一个水货程序员自欺欺人，让自己为自己的低劣感到心安理得的手段。]

Ans：编写程序时不应该执着于过多的检查，比如strncpy函数的实现中传入的指针是否为空等检查是不应该被执行的。程序是程序员必须精心构建的运行系统，程序员应该尽可能的保证每条语句都会按照既定的逻辑运行，即是说strncpy对于程序员来说，程序员应该保证传入的是非空指针的有效参数，而不应该将这个任务交给strncpy函数在内部进行校验，这不是strncpy函数的职责，更不是一种的良好的编程方式。一个优秀的程序员应该保证除了外部输入需要验证合法性之外，其他的程序固定运行逻辑部分的边界条件将被程序员自身保证，而不是依赖于各种边界条件的检查。因为程序本身一种精心设计的系统，其内部的运行架构应该完整而且稳定，在处理完外部输入的不确定之后，程序就应该按照既定的逻辑运行下去，各个模块和函数调用之间传递的参数本身就应该是首先有效的，而不应该动不动就做边界检查。理论上说每一条程序语句都需要达成一定的边界条件才能保证程序正确运行，诸如 x++也是需要保证x不会溢出才能在理论上正确执行，否则就应该先检查x + 1是否溢出，溢出之后如何处理balabala之类的，但这样做在大多数时候都是无耻的。程序本身构造性质如果能保证x++不会溢出，你还需要检查么？显然for(int i = 0;i < 20; i++)中的i++根本不需要做溢出检查！这只是一个简单的例举，然而在精心设计的程序内部，实际上只要机器本身不出现硬件错误（硬件近于函数式编程，几乎不可能出错）那么程序运行中的变量几乎就不可能达到那些所谓的边界条件上去，所以在精心构造的程序内部大部分的边界条件检查都应该避免，并且应该提倡尽量消除这种边界条件的检查，因为实际上这种边界条件如果不是必要，那么就几乎可以肯定的说99%以上的运行时间都不会出现这种边界条件，这样只是让程序做了实际上根本无效的操作，浪费CPU无聊的空转而已。因程序在最终的上线运行时除了防止不可预测的异常和运行时错误之外，其他的程序内部变量的边界条件检查就应该尽可能让程序逻辑本身保证，即程序员应该优雅的保证变量总是正确赋值了，而不是草率的声明和定义这些变量，然后又依靠各种边界条件检查来保证其正确性，有效性。变量本身并不是程序逻辑的一部分，这种多余的边界条件检查对程序本身来说就是一种不需要的负担。程序员在编写程序时就应该保证这样的事情不应该发证，尽可能保证每一条语句，每一个函数，每一个模块像函数式编程那样具有不变形，稳定性，并且结合编译时检查和之后的调试、测试来尽可能重构为不要进行边界检查的新程序逻辑，即程序也许在一开始并不明确哪些地方的边界检查是否必要，但可以通过编译、调试、测试等手段来找出那些非必要的边界检查逻辑，并将之重构为自检查的程序逻辑，让程序在上线之时保持最为精巧、最为简洁，优雅的姿态。

so，在编写函数时一定要谨记什么时候才进行必要的边界条件检查，应该把大多数的边界检查消灭在变量的声明和初始化之时，如果### 不能也应该在程序的主流程进行边界条件检查，将变量传入函数内部做边界条件检查是一种三脚猫式的编程手法。