blocks|key|1519323|text|对我来说，first风格更清晰，而且可能更快。但它需要测试才能准确地表达出来。在第二种情况下，如果type!=ets，则"Size+>+10000“和"Size+<+10000”都将被计算。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1519324|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

As for me first style is more clear and may be faster. But it need test to say it exactly.
In second case if type!=ets then both "Size > 10000" and "Size &lt; 10000" would be evaluated.

blocks|key|1304376|text|您可以通过执行以下操作来使这些示例更加相似：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1304377|case+Type+of
+++ets++when+Size+>+10000+->+...;
+++dets+when+Size+<+10000+->+...;
+++_+->+...
end.|code-block|syntax|javascript|1304378|这对我来说似乎更清楚了。将其拆分为一个单独的函数的好处是，您可以为其指定一个名称，该名称可用作文档并显示在堆栈跟踪中。如果这段代码是一个更大的函数的一部分，我会把它分离出来，否则就没问题了。|1304379|值得考虑的一件事是，在编写错误的情况下，函数将接受ets/dets以外的类型参数。除非这真的是您想要的，否则值得对此条款进行更严格的限制。|1304380|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

You can make these examples more similar by doing:

<pre><code>case Type of
 ets when Size &gt; 10000 -&gt; ...;
 dets when Size &lt; 10000 -&gt; ...;
 _ -&gt; ...
end.
</code></pre>

This seems to be clearer to me. The advantage of splitting this to a separate function is that you get to give it a name which acts as documentation and appears in stack traces. If that snippet is part of a larger function I'd separate it out, otherwise it's okay as is.

One thing worth considering is that error case as written the function will accept Type arguments other than ets/dets. Unless this is really what you want it's worth making this clause more restrictive.

blocks|key|1304445|text|第二种方法是首选方法，特别是如果您可以将子句保持在一行的话：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1304446|maybeCngStor(Sz,+ets)++when+Sz+>+10000+->+something;
maybeCngStor(Sz,+dets)+when+Sz+<+10000+->+somethingelse;
maybeCngStor(_,_)++++++++++++++++++++++->+ignoreit.|code-block|syntax|javascript|1304447|这使得它非常容易阅读和推理。始终选择将来最容易阅读的样式。通常，你会发现一组子句，其中一个是10行，其余的只有一行-将长的子句拆分成一个函数：|1304448|maybeCngStor(Sz,+ets)++when+Sz+>+10000+->+something;
maybeCngStor(Sz,+dets)+when+Sz+<+10000+->+somethingelse();
maybeCngStor(_,_)++++++++++++++++++++++->+ignoreit.

somethingelse()+->
+++(...)
+++Return.|1304449|像布局子句来对齐它们和使用简短的变量名这样的小事情很重要-但不要落入将所有内容都改为P、Q、R的陷阱。|1304450|如果您经常使用记录，一个很好的技巧是将记录与较短的变量进行匹配：|1304451|#record{foo+=+F,+bar+=+B,+baz+=+Bz}+=+Parameter|1304452|这为您提供了简短的变量名，当您在明年圣诞节从10,000英尺的高空跳入函数中寻找bug时，这些名称是有意义的。F显然是Foo，等等，等等。|1304453|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|D|7|10|8|@]|9|@]|A|$E|F]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

The second is the preferred way especially if you can keep the clauses to a single line:

<pre><code>maybeCngStor(Sz, ets) when Sz &gt; 10000 -&gt; something;
maybeCngStor(Sz, dets) when Sz &lt; 10000 -&gt; somethingelse;
maybeCngStor(_,_) -&gt; ignoreit.
</code></pre>

Makes it very easy to read and reason about. Always choose the style that will be easiest to read in the future. Often you find a set of clauses where one is a 10 liner and the rest are one lines only - break out the long one to a function:

<pre><code>maybeCngStor(Sz, ets) when Sz &gt; 10000 -&gt; something;
maybeCngStor(Sz, dets) when Sz &lt; 10000 -&gt; somethingelse();
maybeCngStor(_,_) -&gt; ignoreit.

somethingelse() -&gt;
 (...)
 Return.
</code></pre>

Little things like laying out the clauses to align them and using short variable names matter - but don't fall into the trap of changing everything to P, Q, R.

A good trick if you use records a lot is to match out the records to short variables:

<pre><code>#record{foo = F, bar = B, baz = Bz} = Parameter
</code></pre>

This gives you short variable names that make sense when you parachute into the function from 10,000 feet looking for a bug next Christmas. F obviously is a Foo, etc, etc...

blocks|key|1519463|text|如果在你的函数中，你要做的第一件事就是打开一个case子句，最好把这个顶层子句转换成函数模式匹配。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1519464|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If in your function the first thing you do is open a case clause, it is better to convert this top level clause to function pattern matching.

I've got to the stage where I've written quite a bit of Erlang code now, and I can see some style (bad or good) creeping into the way I've been writing it. This particular idiom I'd like some opinion on - is it better (more readable/faster/whatever) to convert case style statements to function pattern matching?

E.g.

Compare (a contrived example)

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

with

<pre><code>...
maybeChangeStorage(Size, Type)
...

maybeChangeStorage(Size, ets) when Size &gt; 10000 -&gt;
 something;
maybeChangeStorage(Size, dets) when Size &lt; 10000 -&gt;
 somethingelse;
maybeChangeStorage(_,_) -&gt;
 ignoreit.
</code></pre>

I prefer the latter in most cases but I'd be interested in other opinion.

Erlang style - case vs function pattern matching

Erlang

我现在已经编写了相当多的Erlang代码，并且我可以看到一些风格(不管是好是坏)正在悄悄进入我编写它的方式。我想对这个特殊的习惯用法有一些看法-将case样式的语句转换为函数模式匹配是更好(更可读性更好/更快/更快)吗？例如。比较(一个做作的例子)case {Size > 100000, Type} of    {tr...

问Erlang样式-大小写与函数模式匹配
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Erlang样式-大小写与函数模式匹配EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Erlang样式-大小写与函数模式匹配
EN