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

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (15)

我已经到了现在已经写了很多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.

在大多数情况下,我更喜欢后者,但我会对其他意见感兴趣。

提问于
用户回答回答于

第二种是首选的方法,特别是如果你可以将这些子句保留在一行中:

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

这给你一个简短的变量名称,当你在下一个圣诞节寻找bug时,从10,000英尺跳伞到这个函数。F显然是Foo等,等等......

用户回答回答于

你可以通过下列步骤使这些例子更加相似:

case Type of
   ets  when Size > 10000 -> ...;
   dets when Size < 10000 -> ...;
   _ -> ...
end.

这对我来说似乎更加清楚。将它分解为一个单独的函数的好处是你可以给它一个名字,作为文档并出现在堆栈跟踪中。如果该片段是更大功能的一部分,我会将其分开,否则就可以。

值得考虑的一件事是,写入该函数的错误情况将接受除ets / dets之外的类型参数。除非这真的是你想要的,否则值得让这个条款更具限制性。

扫码关注云+社区