我面临一个问题,即递归和使用循环似乎都是自然的解决方案.对于像这样的案件,是否有惯例或"首选方法"?(显然它不像下面那么简单)
Item Search(string desired, Scope scope) {
foreach(Item item in scope.items)
if(item.name == desired)
return item;
return scope.Parent ? Search(desired, scope.Parent) : null;
}
Item Search(string desired, Scope scope) {
for(Scope cur = scope; cur != null; cur = cur.Parent)
foreach(Item item in cur.items)
if(item.name == desired)
return item;
return null;
}
John Feminel.. 56
我赞成递归解决方案:
递归的实现比迭代解决方案简单得多,通常是因为它以迭代方法不能的方式利用问题的结构方面
我可以合理地确定递归的深度不会导致堆栈溢出,假设我们正在谈论以这种方式实现递归的语言
条件1似乎不是这里的情况.迭代解决方案的复杂程度大致相同,因此我坚持使用迭代路由.
我赞成递归解决方案:
递归的实现比迭代解决方案简单得多,通常是因为它以迭代方法不能的方式利用问题的结构方面
我可以合理地确定递归的深度不会导致堆栈溢出,假设我们正在谈论以这种方式实现递归的语言
条件1似乎不是这里的情况.迭代解决方案的复杂程度大致相同,因此我坚持使用迭代路由.
如果绩效很重要,那么对两者进行基准测试并在合理的基础上进 如果没有,则根据复杂性进行选择,并考虑可能的堆栈溢出.
经典着作"编程风格的元素"(由Kernighan和Plauger 撰写)有一个指南,即算法应遵循数据结构.也就是说,递归结构通常使用递归算法更清晰地处理.
递归用于表示以更容易理解的形式自然递归的算法."自然递归"算法是这样一种算法,其中答案是根据较小子问题的答案构建的,这些子问题又是根据较小的子问题的答案等构建的.例如,计算因子.
在一种不起作用的编程语言中,迭代方法几乎总是比递归方法更快,更有效,因此使用递归的原因是清晰度,而不是速度.如果递归实现最终不如迭代实现那么清晰,那么一定要避免它.
在这种特殊情况下,我会判断迭代实现更清晰.
如果您使用的是函数式语言(似乎不是这样),请使用递归.如果没有,那么在项目中工作的其他人可能会更好地理解循环.当然,某些任务(如递归搜索目录)比其他任务更适合递归.
此外,如果代码无法针对尾端递归进行优化,则循环更安全.
使用循环.它更容易阅读和理解(阅读代码总是比编写代码困难得多),并且通常要快得多.