当代码流是这样的:
if(check())
{
...
...
if(check())
{
...
...
if(check())
{
...
...
}
}
}
我通常看到这种方法可以避免上述混乱的代码流:
do {
if(!check()) break;
...
...
if(!check()) break;
...
...
if(!check()) break;
...
...
} while(0);
有什么更好的方法可以避免这种工作/黑客，从而使其成为更高级别(行业级别)的代码?
任何跳出盒子的建议都是欢迎的!
当前回答
我不是c++程序员，所以我不会在这里写任何代码，但到目前为止还没有人提到面向对象的解决方案。下面是我的猜测:
拥有一个通用接口，该接口提供了一个方法来评估单个条件。现在，您可以在包含有问题的方法的对象中使用这些条件的实现列表。遍历列表并计算每个条件，如果其中一个条件失败，可能会提前爆发。
这样的设计很好地遵循了开/闭原则，因为在初始化包含相关方法的对象时，可以很容易地添加新的条件。您甚至可以向接口添加第二个方法，该方法用于条件评估，返回条件的描述。这可以用于自文档系统。
但是，缺点是由于使用了更多的对象和遍历列表，所涉及的开销稍微多一些。
其他回答
如果你的代码有一个很长的If ..else If ..else语句块，你可以尝试在函子或函数指针的帮助下重写整个块。这可能并不总是正确的解决方案，但通常是正确的。
http://www.cprogramming.com/tutorial/functors-function-objects-in-c++.html
在函数中隔离这些决策并使用返回而不是中断被认为是可以接受的实践。虽然所有这些检查都对应于与函数相同的抽象级别，但这是一种非常符合逻辑的方法。
例如:
void foo(...)
{
if (!condition)
{
return;
}
...
if (!other condition)
{
return;
}
...
if (!another condition)
{
return;
}
...
if (!yet another condition)
{
return;
}
...
// Some unconditional stuff
}
typedef bool (*Checker)();
Checker * checkers[]={
&checker0,&checker1,.....，&checkerN,NULL
};
bool checker1(){
if(condition){
.....
.....
return true;
}
return false;
}
bool checker2(){
if(condition){
.....
.....
return true;
}
return false;
}
......
void doCheck(){
Checker ** checker = checkers;
while( *checker && (*checker)())
checker++;
}
怎么样?
使用异常。您的代码将看起来更加清晰(并且创建异常正是为了处理程序执行流中的错误)。有关清理资源(文件描述符，数据库连接等)，请阅读文章“为什么c++不提供一个“finally”结构?”
#include <iostream>
#include <stdexcept> // For exception, runtime_error, out_of_range
int main () {
try {
if (!condition)
throw std::runtime_error("nope.");
...
if (!other condition)
throw std::runtime_error("nope again.");
...
if (!another condition)
throw std::runtime_error("told you.");
...
if (!yet another condition)
throw std::runtime_error("OK, just forget it...");
}
catch (std::runtime_error &e) {
std::cout << e.what() << std::endl;
}
catch (...) {
std::cout << "Caught an unknown exception\n";
}
return 0;
}
我就是这么做的。
void func() {
if (!check()) return;
...
...
if (!check()) return;
...
...
if (!check()) return;
...
...
}
