if-statement - 二郎: nested cases

Question

我对 Erlang 很陌生。我试图找出列表索引是否超出范围(在尝试之前)所以我想用类似的东西做一个 if 子句

if lists:flatlength(A) < DestinationIndex ....

我发现这些函数结果不能用于 if 守卫，所以我改用了 case。这导致嵌套的 case 语句

case Destination < 1 of
    true -> {ok,NumberOfJumps+1};
    false ->
    case lists:flatlength(A) < Destination of
        true -> 
            doSomething;
        false ->
            case lists:member(Destination,VisitedIndices) of
                true -> doSomething;
                false -> 
                    doSomethingElse
            end
    end
end.

我发现这在可读性和代码风格方面很糟糕。这是您在 erlang 中执行此类操作的方式，还是有更优雅的方式来执行此操作？

提前致谢

Answer 1

在你把下面的内容当作一些神奇的福音之前，请注意这个函数的输入方式几乎肯定是单调的。在达到这一点之前，您应该设法限制案例——对嵌套案例的需求本身通常是一种代码味道。有时这确实是不可避免的，但我强烈怀疑这方面的某些方面可以在代码的早期进行简化(尤其是对正在传递的数据结构及其含义进行更多考虑)。
看不到变量 A 的位置来自，我在这里制作一个作为参数。另外，在没有看到这个函数是如何输入的情况下，我正在组成一个函数头，因为如果没有其余的函数去执行，很难确定什么。
说了这么多，让我们稍微重构一下:
首先，我们想摆脱一个我们知道可以进入 guard 的东西，那就是你的第一个 case检查是否 Destination < 1 .让我们考虑一下我们真的想调用一个公共(public)函数的两个不同子句，而不是使用一个案例:

foo(Destination, NumberOfJumps, _, _) when Destination < 1 ->
    {ok, NumerOfJumps + 1};
foo(Destination, _, VisitedIndices, A) ->
    case lists:flatlength(A) < Destination of
        true -> doSomething;
        false ->
            case lists:member(Destination,VisitedIndices) of
               true  -> doSomething;
               false -> doSomethingElse
            end
    end.

不算太奇怪。但是那些仍然存在的嵌套案例......它们有些烦人。这就是我怀疑可以在其他地方做些什么来减轻代码中更早的路径选择的地方。但是让我们假设你无法控制这些东西。在这种情况下， bool 值和 if 的赋值可以是可读性增强器:

foo(Destination, NumberOfJumps, _, _) when Destination < 1 ->
    {ok, NumberOfJumps + 1};
foo(Destination, _, VisitedIndices, A) ->
    ALength = lists:flatlength(A) < Destination,
    AMember = lists:member(Destionation, VisitedIncides),
    NextOp =
        if
            ALength     -> fun doSomething/0;
            AMember     -> fun doSomething/0;
            not AMember -> fun doSomethingElse/0
        end,
    NextOp().

在这里，我刚刚切入正题，并通过将结果分配给变量来确保我们只执行每个可能昂贵的操作一次——但这让我非常不舒服，因为我不应该一开始就处于这种情况。
在任何情况下，这样的东西都应该与之前的代码一样进行测试，并且在此期间可能更具可读性。但是您应该寻找其他简化的地方。特别是这个 VisitedIndices业务感觉很可疑(为什么我们不知道 Destination 是否是成员？)，变量 A在我们到达这个函数之后需要展平很奇怪(为什么它还没有展平？为什么有这么多？)，和 NumberOfJumps感觉像是一个蓄能器，但它的存在是神秘的。
你可能会问，是什么让我对这些变量感到奇怪？唯一一直使用的是 Destination -- 其他的只用在 foo/4 的一个子句中。或其他，但不是两者兼而有之。这让我认为这应该是执行链上游某处的不同执行路径，而不是在 super 决策类型函数中全部结束。
编辑
对手头的问题进行更全面的描述(引用下面评论中的讨论)，考虑这是如何解决的:

-module(jump_calc).
-export([start/1]).

start(A) ->
    Value = jump_calc(A, length(A), 1, 0, []),
    io:format("Jumps: ~p~n", [Value]).

jump_calc(_, Length, Index, Count, _) when Index < 1; Index > Length ->
    Count;
jump_calc(Path, Length, Index, Count, Visited) ->
    NewIndex = Index + lists:nth(Index, Path),
    NewVisited = [Index | Visited],
    NewCount = Count + 1,
    case lists:member(NewIndex, NewVisited) of
        true  -> NewCount;
        false -> jump_calc(Path, Length, NewIndex, NewCount, NewVisited)
    end.

始终尝试尽可能多地预先加载处理，而不是一遍又一遍地执行相同的计算。考虑一下我们可以多么容易地将每个迭代都挡在守卫后面，以及因此我们甚至不必编写多少有条件的东西。函数匹配是一个强大的工具——一旦你掌握了它的窍门，你就会真正开始喜欢 Erlang。