Erlang风格 - 案例与功能模式匹配

我已经到了现在我写了很多Erlang代码的阶段,我可以看到一些风格(坏或好)悄悄进入我写作的方式.这个特别的习惯我想要一些意见 - 将案例样式语句转换为函数模式匹配更好(更可读/更快/更好)？

例如

比较(一个人为的例子)

case {Size > 100000, Type} of
    {true, ets } ->
         %% Do something to convert to dets
         something;
    {false, dets} ->
         %% do something to convert to ets
         somethingelse;
    _ ->
         ignoreit
end;

同

...
maybeChangeStorage(Size, Type)
...

maybeChangeStorage(Size, ets) when Size > 10000 ->
   something;
maybeChangeStorage(Size, dets) when Size < 10000 ->
   somethingelse;
maybeChangeStorage(_,_) ->
   ignoreit.

在大多数情况下,我更喜欢后者,但我对其他观点感兴趣.

1> Gordon Guthr..：

---

第二种是首选方式,尤其是如果您可以将子句保留在一行中:

maybeCngStor(Sz, ets)  when Sz > 10000 -> something;
maybeCngStor(Sz, dets) when Sz < 10000 -> somethingelse;
maybeCngStor(_,_)                      -> ignoreit.

使其易于阅读和推理.始终选择将来最容易阅读的风格.通常你会发现一组子句,其中一个是10个衬里,其余的只有一行 - 将长的一个分解为一个函数:

maybeCngStor(Sz, ets)  when Sz > 10000 -> something;
maybeCngStor(Sz, dets) when Sz < 10000 -> somethingelse();
maybeCngStor(_,_)                      -> ignoreit.

somethingelse() ->
   (...)
   Return.

像布置条款以使它们对齐并使用短变量名称这样的小事情很重要 - 但不要陷入将所有内容更改为P,Q,R的陷阱.

如果你经常使用记录的一个好方法是将记录与短变量匹配:

#record{foo = F, bar = B, baz = Bz} = Parameter

这为您提供了一些简短的变量名称,当你从下一个圣诞节寻找一个错误的10,000英尺降落到该功能时,这些名称是有意义的.F显然是Foo等等......

---

在大多数情况下,我真的很喜欢功能匹配.虽然我的周期通常类似于:首先写一个案例陈述.稍后重构为函数.我倾向于编写代码,然后重新进行重构.我越接近一条线就能让我更开心.

2> Rodrigue..：

---

了解一些Erlang的好消息,有一小段关于何时选择case以及何时使用function.提到了两件事:

它们在VM中以相同的方式表示,因此两种解决方案之间的性能没有差异.

如果您需要对多个参数使用防护,则使用函数可能会更好地阅读.

总而言之,这主要是风格和品味的问题.