blocks|key|1031708|text|它们做的是完全相同的事情，所以就实用性而言，这是一个偏好问题。这样或那样的性能差异很小吗？谁知道呢，但它肯定是微不足道的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1031709|当模式长度不固定时，量词更有用(也是必需的)，例如\d{12,16}、\d{2,}等。|offset|length|style|CODE|1031710|我更喜欢比\d\d\d\d更容易被我的大脑解析的\d{4}|1031711|另外，如果你匹配的是一个字符类而不是一个简单的数字呢？[aeiouy0-9]{4}还是[aeiouy0-9][aeiouy0-9][aeiouy0-9][aeiouy0-9]？|1031712|entityMap^0|0|P|9|Z|6|0|5|8|O|5|0|R|E|17|18|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@$D|P|E|Q|F|G]|$D|R|E|S|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@$D|U|E|V|F|G]|$D|W|E|X|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|Y|8|@$D|Z|E|10|F|G]|$D|11|E|12|F|G]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|M|$]]

They do the exact same thing, so as far as practicality it's a matter of preference. Is there a tiny performance difference one way or the other? Who knows but it's surely insignificant.

The quantifiers are more useful (and required) when the pattern length isn't fixed, for example <code>\d{12,16}</code>, <code>\d{2,}</code>, etc.

I prefer <code>\d{4}</code> which is easier for my brain to parse than <code>\d\d\d\d</code>

Also what if you're matching a character class rather than a simple digit? <code>[aeiouy0-9]{4}</code> or <code>[aeiouy0-9][aeiouy0-9][aeiouy0-9][aeiouy0-9]</code> ?

blocks|key|1528021|text|任何超过3或4次的重复都很难一目了然。我认为这是一个令人信服的理由。最重要的是，使用量词是一种“密集”的方式来表达重复的信息。对我来说，这就像是复制粘贴代码“重用”与编写真正可重用的代码之间的区别。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1528022|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|$]]

Any repetition of more than 3 or 4 will be hard to count at a glance. I consider this a compelling reason. On top of that, using the quantifier is a "denser" way to express the repeated information. To me, it's like the difference between copy-and-paste code "reuse" versus writing truly reusable code.

blocks|key|2936511|text|最好的想法是，当他想要找到一组10%2B字母时，他将不得不使用量词而不是重复，最好习惯正确的方式，此外，如果他坚持使用重复来处理更大的字符集，某人在尝试计算它们时会遇到一些麻烦，如果用量词标记就不需要了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2936512|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|$]]

It's best to think that when he wants to find a set of 10+ letters he will have to use the quantifier rather than repetition, it's better to get used to the right way, besides, if he insists on using repetition for larger sets of characters, someone will have some trouble while trying to count them, which would not be needed if it was marked with a quantifier.

blocks|key|282861|text|没有绝对的可读性这回事。这是人们可以单独识别的，这就是为什么人们经常理解他们的代码，而其他人却不能。如果他从不使用量词，他总是会认为量词很难读懂，因为他从来不会去摸索它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|282862|我经常发现，当人们说“可读性更好”时，他们真正的意思是“这是我已经知道的东西”或“这是我第一次写的东西”。然而，在这里不一定是这样的。|282863|像{4}这样的绝对量词更容易指定，也更容易与其他程序员交流。谁想用手数一下\d的个数？你编写代码给其他人阅读，所以不要让他们的生活变得更困难。|offset|length|style|CODE|282864|但是，您可能遗漏了该代码中的bug，因为您关注的是量词问题。Perl锚点允许在字符串的末尾换行，如果出现$最佳实践狂热分子并盲目地将/xsm添加到所有正则表达式中(这是我见过很多次的痛苦经历)，那么$将允许更多的无效输出。您可能希望使用\z绝对字符串结束锚点。|282865|这不是发生在你的案例中，而是代码审查倾向于变成风格或语法审查(因为它们更容易被注意到)，并且实际上错过了检查适当的和预期的行为和正确的设计的要点。通常，样式问题不值得考虑您可以花费时间来改进代码的所有其他方法。:)|282866|entityMap^0|0|0|1|3|11|2|0|1G|1|1U|4|2R|1|3A|2|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@$F|S|G|T|H|I]|$F|U|G|V|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@$F|X|G|Y|H|I]|$F|Z|G|10|H|I]|$F|11|G|12|H|I]|$F|13|G|14|H|I]]|9|@]|A|$]]|$1|L|3|M|5|6|7|15|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|O|$]]

There's no such thing as absolute readability. There's what people can individually recognize, which is why people often understand their code while nobody else can. If he never uses quantifiers, he's always going to think quantifiers are hard to read because he never learns to grok them.

I most often find that people say "more readable" when they really mean "that's what I know already" or "that's what I wrote the first time". That's not necessarily the case here, though.

An absolute quantifier like <code>{4}</code> is just easier to specify and communicate to other programmers. Who wants to count the number of <code>\d</code>s by hand? You write code for other people to read, so don't make their life harder.

However, you might have missed the bug in that code because you were focused on the quantifier issue. The <code>$</code> anchor allows a newline at the end of the string, and if a Perl Best Practices zealot comes along and blindly adds <code>/xsm</code> to all regexes (a painful experience I've seen more than a few times), that <code>$</code> allows even more invalid output. You probably want the <code>\z</code> absolute end-of-string anchor instead.

Not that it happened in your case, but code reviews tend to turn into style or syntax reviews (because those are easier to notice) and actually miss the point of checking for proper and intended behavior and correct design. Often the style problems aren't worth worrying about considering all of the other ways you could spend time to improve code. :)

blocks|key|283918|text|{4}比\d\d\d\d更容易维护，因为它的伸缩性更好。例如，如果以后需要将其更改为匹配11位数字，则只需将4更改为11，而不必在regex中添加14个字符。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|283919|entityMap^0|0|3|4|8|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

<code>{4}</code> is easier to maintain than <code>\d\d\d\d</code> because it scales better. For example, if you later need to change it to match 11 digits, you could simply change the 4 to an 11, instead of having to add 14 characters to your regex.

blocks|key|283941|text|关于可读性...一些Perl程序员使用非常罕见的特性，希望它们是可读的，然而，这需要理解这种罕见的特性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|283942|有许多regexp新手不了解{4}是什么。|283943|关于优点，第二种可能更好，因为它在regexp引擎中占用较少的数组元素。除非你是一个真正的程序员，否则你不会将性能优化到纳秒。|283944|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

About readability... some Perl programmers uses very rare features, hoping them to be readable, however, it requires the understanding of that rare feature.

There are many regexp newbies who do not understand what {4} is.

About benefits, the second one may be better because it takes less array elements in the regexp engine. Unless you are a Real Programmer, you won't be optimizing performance to nanoseconds.

blocks|key|1528241|text|像许多事情一样，这是一个你想把它带到什么程度的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1528242|一个真实的例子。|1528243|比较：|1528244|my+@lines+=+$header+=~+m/([%5E\n\r]{13}%7C[%5E\n\r]%2B)/g;+#split+header+into+groups+of+up+to+13+characters|code-block|syntax|javascript|1528245|至|1528246|my+@lines+=+$header+=~+m/([%5E\n\r][%5E\n\r][%5E\n\r][%5E\n\r][%5E\n\r][%5E\n\r][%5E\n\r][%5E\n\r][%5E\n\r][%5E\n\r][%5E\n\r][%5E\n\r][%5E\n\r]%7C[%5E\n\r]%2B)/g;+#split+into+groups+of+up+to+13+characters|1528247|你还能找到管道'%7C‘吗？|1528248|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|V|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|X|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

Like many things, it is a matter of how far you want to take it.

A real example.

Compare:

<pre><code>my @lines = $header =~ m/([^\n\r]{13}|[^\n\r]+)/g; #split header into groups of up to 13 characters
</code></pre>

to

<pre><code>my @lines = $header =~ m/([^\n\r][^\n\r][^\n\r][^\n\r][^\n\r][^\n\r][^\n\r][^\n\r][^\n\r][^\n\r][^\n\r][^\n\r][^\n\r]|[^\n\r]+)/g; #split into groups of up to 13 characters
</code></pre>

Can you still find the pipe '|'?

blocks|key|282954|text|我可能会使用任何一种形式，这取决于具体情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|282955|让我们忽略在一行中重复96次的自定义字符类的复杂性，转而关注编写得很好的代码。|282956|考虑一下：|282957|$foo+=~+m{
++++++++(\d\d\d\d)
++++[+]+(\d\d\d?)
++++[+]+(\w\w)
}x;|code-block|syntax|javascript|282958|我曾经使用过这样的代码来解析来自天气传感器的数据。我使用这种格式是因为它与制造商的文档非常匹配。这对于“固定宽度”的数据格式非常有效，这些格式并不完全符合固定宽度字段的承诺(这在实践中非常常见)。|282959|您可以争辩说，我应该将空格放在单独的行上，或者与前面的字段放在同一行上，而不是与后面的字段放在一行上。但这只是格式化，对于perltidy来说确实是一个问题。|282960|在其他情况下，我使用了如下代码：|282961|$foo+=~+m{+
++++++++(+\d{4}+++)
++++[+]+(+\d{2,3}+)
++++[+]+(+\w{2}+++)
}x;|282962|为了保持上述代码的可读性，您必须添加更多的空格，并尝试更多的格式化。|282963|第二种样式的可伸缩性更好，添加自定义字符类和宽字段不会破坏可读性。|282964|最重要的是在给定的正则表达式内保持一致。哦，千万别这么做：|282965|$foo+=~+m{+
++++++++(+\d\d\d\d+)
++++[+]+(+\d{2,3}++)
++++[+]+(+\w\w+++++)
}x;|282966|归根结底，代码执行两个功能。最广为人知的功能是它告诉计算机该做什么。但代码最重要的功能是告诉维护程序员计算机正在做什么，这一功能在很大程度上被忽视了。|282967|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|16|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|17|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|18|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|19|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Q|3|R|5|H|7|1B|8|@]|9|@]|A|$I|J]]|$1|S|3|T|5|6|7|1C|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1D|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1E|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|H|7|1F|8|@]|9|@]|A|$I|J]]|$1|10|3|11|5|6|7|1G|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|13|$]]

I would be likely to use either form, depending on the circumstances.

Let's ignore the strawman complexity of custom character-classes repeated 96 times all on one line, and instead focus on nicely written code.

Consider:

<pre><code>$foo =~ m{
 (\d\d\d\d)
 [ ] (\d\d\d?)
 [ ] (\w\w)
}x;
</code></pre>

I've used code like this to parse data from weather sensors. I use this format because it closely matches the manufacturer's documentation. This works pretty well for "fixed width" data formats that don't quite live up to the promise of fixed width fields (this is distressingly common in practice).

You can argue that I should put the spaces on separate lines or on the same line as the preceding field, rather than on line with the subsequent field. But that is just formatting, and is truly a problem for perltidy.

In other cases, I have used code like this:

<pre><code>$foo =~ m{ 
 ( \d{4} )
 [ ] ( \d{2,3} )
 [ ] ( \w{2} )
}x;
</code></pre>

To keep the above readable, you've got to add more whitespace, and play with formatting a bit more.

The second style scales with complexity better -- adding custom character classes and wide fields does not break readability.

The most important thing is to be consistent within a given regex. IOW, never do this:

<pre><code>$foo =~ m{ 
 ( \d\d\d\d )
 [ ] ( \d{2,3} )
 [ ] ( \w\w )
}x;
</code></pre>

Ultimately, code performs two functions. The most well known function is that it tells the computer what to do. But the most important, yet largely overlooked function of code is to tell the maintenance programmer what the computer is doing.

I was performing a code review for a colleague and he had a regular expression that looked like this:

<pre><code>if ($value =~ /^\d\d\d\d$/) {
 #do stuff
}
</code></pre>

I told him he should change it to:

<pre><code>if ($value =~ /^\d{4}$/) {
 #do stuff
}
</code></pre>

To which he replied that he preferred the first for readability (I find the second more readable, but that's a religious debate I'll save for another day).

My question: is there an actual benefit to one over the other?

Is there a compelling reason to use quantifiers in Perl regular expressions instead of just repeating the character?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在为一位同事执行代码审查，他有一个正则表达式，看起来像这样：if ($value =~ /^\d\d\d\d$/) {    #do stuff}我告诉他应该改成：if ($value =~ /^\d{4}$/) {    #do stuff}对于这一点，他回答说，为了可读性，他更喜欢第一种(我发现第二种更具可读性...

问是否有令人信服的理由在Perl正则表达式中使用量词，而不是仅仅重复字符？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问是否有令人信服的理由在Perl正则表达式中使用量词，而不是仅仅重复字符？EN