blocks|key|3365980|text|Obligatory.|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3365981|这真的要归结为正则表达式。如果是这个庞大的整体表达式，那么是的，这是一个可维护性问题。如果你能简洁地表达它们(也许是通过分解它们)，或者如果你有好的注释和工具来帮助你理解它们，那么它们就可以成为一个强大的工具。|3365982|entityMap|0|LINK|mutability|MUTABLE|url|http://www.codinghorror.com/blog/archives/001016.html^0|0|B|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

<a href="http://www.codinghorror.com/blog/archives/001016.html" rel="nofollow noreferrer">Obligatory.</a>

It really comes down to the regex. If it's this huge monolithic expression, then yes, it's a maintainability problem. If you can express them succinctly (perhaps by breaking them up), or if you have good comments and tools to help you understand them, then they can be a powerful tool.

blocks|key|360775|text|正则表达式并不是做某事的唯一方法。从逻辑上讲，您可以在代码中执行正则表达式所能做的一切。正则表达式只是|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360776|360777|Fast|ordered-list-item|360778|Tested和Proven|360779|Powerful|360780|360781|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|N|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|O|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|P|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|Q|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|L|$]]

Regex's aren't the ONLY way to do something. You can do logically in code everything that a regular expression can. Regular expressions are just

<ol>
<li>Fast</li>
<li>Tested and Proven</li>
<li>Powerful</li>
</ol>

blocks|key|3153130|text|复杂的正则表达式对我来说是一触即发的。编写它，测试它，当它工作时，写一个评论它做什么，我们就很好了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3153131|然而，在许多情况下，您可以将正则表达式分解为更小的部分，也许可以编写一些文档完整的代码来组合这些正则表达式。但是，如果您在代码中发现了多行正则表达式，那么您最好不要成为必须维护它的人:)|3153132|听起来耳熟吗？这在任何代码中都或多或少是正确的。您不希望有很长的方法，不想有很长的类，也不想有很长的正则表达式，尽管方法和类到目前为止更容易重构。但本质上，这是相同的概念。|3153133|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|$]]

Complex regexes are fire-and-forget for me. Write it, test it, and when it works, write a comment what it does and we're fine.

In many cases, however, you can breakdown regular expressions to smaller parts, maybe write some well-documented code that combines these regexes. But if you find a multi-line regex in your code, you better be not the one who must maintain it :)

Sounds familiar? That's more or less true of any code. You don't want to have very long methods, you don't want to have very long classes, and you don't want to have very long regular expressions, though methods and classes are by far easier to refactor. But in essence, it's the same concept.

blocks|key|365522|text|关于正则表达式的名言：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|365523|365524|“有些人在遇到问题时会想：”我知道，我会用正则表达式。现在他们有两个问题了。“--扎温斯基|blockquote|365525|365526|365527|当我使用正则表达式时，我发现它们是可维护的，但它们在特殊情况下使用。通常有一种更好的、非正则表达式的方法来做几乎所有的事情。|365528|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|M|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|N|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Q|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|K|$]]

famous quote about regexes: 

<blockquote>
 "Some people, when confronted with a problem, think 
 “I know, I'll use regular expressions.” Now they have two problems." -- Jamie Zawinski
</blockquote>

When I do use regexes, I find them to be maintainable, but they are used in special cases. There is usually a better, non-regex method for doing almost everything.

blocks|key|3153228|text|只有在你不理解正则表达式的情况下，它才会变得很神奇。生产代码中的任何小改动都可能导致大问题，所以在我看来，这不是不使用正则表达式的好理由，彻底的测试应该指出任何问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3153229|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 only seems like magic if you don't understand the regex. Any number of small changes in production code can cause major problems so that is not a good reason, in my opinion, to not use regex's. Thorough testing should point out any problems.

blocks|key|362264|text|当有意识地使用正则表达式时，它是一种强大的机制，可以让您从可能的文本解析中解脱出来。当然，它们应该被正确有效地记录下来，以便验证初始假设是否仍然有效，并以其他方式相应地更新它们。关于维护，IMHO最好是更改一行代码(正则表达式模式)，而不是理解一行又一行的解析代码或任何正则表达式的用途。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|362265|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|$]]

When used consciously regular expressions are a powerful mechanism that spares you from lines and lines of possible text parsing. They should of course be documented correctly and efficiently tracked in order to verify if initial assumptions are still valid and otherwise updated them accordingly. Regarding maintenance IMHO is better to change a single line of code (the regular expression pattern) than understand lines and lines of parsing code or whatever the regular expressions purpose is.

blocks|key|360883|text|如果正则表达式很长且难以理解，使得它们很难维护，那么应该对它们进行注释。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360884|许多正则表达式实现允许您在正则表达式中填充空格和注释。|360885|请参阅https://www.regular-expressions.info/freespacing.html#parenscomment|offset|length|360886|和编码恐怖：Regular+Expressions:+Now+You+Have+Two+Problems|360887|360888|我所见过的任何使用正则表达式的代码都倾向于使用它们作为一个黑盒：|blockquote|360889|360890|360891|如果你所说的黑盒是指抽象，那就是所有的编程，试图抽象掉困难的部分(解析字符串)，这样你就可以专注于问题域(我想匹配哪种类型的字符串)。|360892|360893|即使是一个很小的更改，通常也会导致一个完全不同的正则表达式。|360894|360895|360896|这对任何代码都是正确的。只要您正在测试您的正则表达式以确保它与您期望的字符串匹配，最好使用单元测试，那么您应该对更改它们充满信心。|style|BOLD|360897|编辑:还请阅读Jeff对此答案的关于生产代码的评论。|360898|entityMap|0|LINK|mutability|MUTABLE|url|https://www.regular-expressions.info/freespacing.html#parenscomment|1|http://www.codinghorror.com/blog/archives/001016.html^0|0|0|3|1V|0|0|6|1A|1|0|0|0|0|0|0|0|0|0|0|19|4|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1D|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1E|8|@]|9|@$F|1F|G|1G|1|1H]]|A|$]]|$1|H|3|I|5|6|7|1I|8|@]|9|@$F|1J|G|1K|1|1L]]|A|$]]|$1|J|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|1N|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|S|3|T|5|M|7|1S|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1V|8|@$F|1W|G|1X|Y|Z]]|9|@]|A|$]]|$1|10|3|11|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]]|13|$14|$5|15|16|17|A|$18|19]]|1A|$5|15|16|17|A|$18|1B]]]]

If regexes are long and impenetrable, making them hard to maintain then they should be commented.
A lot of regex implementations allow you to pad regexes with whitespace and comments. 
See <a href="https://www.regular-expressions.info/freespacing.html#parenscomment" rel="nofollow noreferrer">https://www.regular-expressions.info/freespacing.html#parenscomment</a> 
and Coding Horror: <a href="http://www.codinghorror.com/blog/archives/001016.html" rel="nofollow noreferrer">Regular Expressions: Now You Have Two Problems</a>
<blockquote>
Any code I've seen that uses Regexes tends to use them as a black box:
</blockquote>
If by black box you mean abstraction, that's what all programming is, trying to abstract away the difficult part (parsing strings) so that you can concentrate on the problem domain (what kind of strings do I want to match).
<blockquote>
even a small change can often result in a completely different regex.
</blockquote>
That's true of any code. As long as you are testing your regex to make sure it matches the strings you expect, ideally with unit tests, then you should be confident at changing them.
Edit: please also read Jeff's comment to this answer about production code.

blocks|key|365585|text|对任何语言中的任何代码进行微小的更改都可能导致完全不同的结果。其中一些甚至会阻止编译。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|365586|将正则表达式替换为"C“或"C#”或"Java“或"Python”或"Perl“或"SQL”或"Ruby“或"awk”或...任何事情，真的，你都会得到同样的问题。|365587|正则表达式只是另一种语言，Huffman+coded在字符串匹配方面非常有效。就像Java、Perl、PHP，尤其是SQL一样，每种语言都有优缺点，在编写(或维护)时需要了解所用的语言，才有希望提高效率。|offset|length|365588|编辑:+Mike，regex是霍夫曼编码的，常见的事情比稀有的事情要短。文本的文字匹配通常是单个字符(您想要匹配的字符)。存在特殊字符--常见的字符很短。特殊结构，如(?:)较长。这些都不是通用语言中常见的东西，比如Perl、C%2B%2B等，所以霍夫曼编码就是针对这种专门化的。|365589|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Huffman_coding^0|0|0|D|D|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$F|U|G|V|1|W]]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

Small changes to any code in any language can result in completely different results. Some of them even prevent compilation.

Substitute regex with "C" or "C#" or "Java" or "Python" or "Perl" or "SQL" or "Ruby" or "awk" or ... anything, really, and you get the same question.

Regex is just another language, <a href="http://en.wikipedia.org/wiki/Huffman_coding" rel="nofollow noreferrer">Huffman coded</a> to be efficient at string matching. Just like Java, Perl, PHP, or especially SQL, each language has strengths and weaknesses, and you need to know the language you're writing in when you're writing it (or maintaining it) to have any hope of being productive.

Edit: Mike, regex's are Huffman coded in that common things to do are shorter than than rarer things. Literal matches of text is generally a single character (the one you want to match). Special characters exist - the common ones are short. Special constructs, such as (?:) are longer. These are not the same things that would be common in general-purpose languages like Perl, C++, etc., so the Huffman coding was targetted at this specialisation.

blocks|key|3153398|text|我在我的应用程序中使用它们，但我将实际的regEx表达式保存在配置文件中，因此，如果我正在解析的源文本(例如电子邮件)由于某种原因改变了格式，我可以快速更新配置以处理这些更改，而无需重新构建应用程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3153399|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|$]]

I use them in my apps but I keep the actual regEx expression in the configuration file so if the source text I'm parsing (an email for example) changes format for some reason I can quickly update the config to handle the change without re-building the app.

blocks|key|365620|text|我不知道您使用的是哪种语言，但是Perl+-例如-支持x标志，所以除非转义，否则正则表达式中的空格将被忽略，所以您可以将其分成几行，并对所有内容进行内联注释：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|365621|$foo+=~+m{
++++(some-thing)++++++++++#+matches+something
++++\s*+++++++++++++++++++#+matches+any+amount+of+spaces
++++(match+another+thing)+#+matches+something+else
}x;|code-block|syntax|javascript|365622|这有助于使长正则表达式更具可读性。|365623|entityMap^0|R|1|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|S|8|@]|D|@]|E|$]]|$1|M|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|N|$]]

I don't know which language you're using, but Perl - for example - supports the <code>x</code> flag, so spaces are ignored in regexes unless escaped, so you can break it into several lines and comment everything inline:

<pre><code>$foo =~ m{
 (some-thing) # matches something
 \s* # matches any amount of spaces
 (match another thing) # matches something else
}x;
</code></pre>

This helps making long regexes more readable.

blocks|key|360932|text|Regex肯定被称为“只写”编程语言。然而，我不认为这意味着你应该避免它们。我只是觉得你应该出于他们的本意去评论他们。我通常不太喜欢解释一行代码的注释，我可以阅读代码，但正则表达式是个例外。评论所有的东西！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360933|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|$]]

Regex has been referred to as a "write only" programming language for sure. However, I don't think that means you should avoid them. I just think you should comment the hell out of their intent. I'm usually not a big fan of comments that explain what a line does, I can read the code for that, but Regexs are the exception. Comment everything!

blocks|key|3366316|text|正则表达式是做事情的方法吗？这取决于任务。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3366317|就像所有的编程一样，没有固定的正确或错误的答案。|3366318|如果regexp快速而简单地解决了特定的任务，那么它可能比更冗长的解决方案更好。|3366319|如果regexp试图完成一项复杂的任务，那么更详细的内容可能更易于理解和维护。|3366320|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Are regexes the way to do things? It depends on the task.

As with all things programming, there isn't a hard and fast right, or wrong answer.

If a regexp solves a particular task quickly and simply, then it's possibly better then a more verbose solution.

If a regexp is trying to achieve a complicated task, then something more verbose might be simpler to understand and therefore maintain.

blocks|key|3153489|text|我有一个彻底评论非平凡正则表达式的策略。这意味着描述并证明每个原子与自身不匹配。一些语言(比如Python)提供了忽略空格并允许注释的“详细”正则表达式；只要有可能，就使用它。否则，在regex上方的注释中一个原子接一个原子。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3153490|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|$]]

I have a policy of thoroughly commenting non-trivial regexes. That means describing and justifying each atom that doesn't match itself. Some languages (Python, for one) offer "verbose" regexes that ignore whitespace and allow comments; use this whenever possible. Otherwise, go atom by atom in a comment above the regex.

blocks|key|362962|text|我通常会写一个扫描仪规范文件。扫描器，或“扫描器生成器”本质上是一个优化的文本解析器。因为我通常使用Java语言，所以我首选的方法是JFlex+(http://www.jflex.de)，但也有Lex、YACC和其他一些方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|362963|扫描程序处理可以定义为宏的正则表达式。然后，当正则表达式与文本的一部分匹配时实现回调。|362964|当涉及到代码时，我有一个包含所有解析逻辑的规范文件。我通过所选的扫描器生成器工具运行它，以便以所选的语言生成源代码。然后，我只需将所有这些封装到一个解析器函数或某种类型的类中。这种抽象使得管理所有正则表达式逻辑变得很容易，而且性能非常好。当然，如果你只使用一个或两个正则表达式，这就有点夸张了，而且很容易花2-3天来了解地狱发生了什么，但如果你曾经使用过，比如说5个、6个或30个，它就变成了一个非常好的功能，实现解析逻辑只需要几分钟，而且它们很容易维护和记录。|362965|entityMap|0|LINK|mutability|MUTABLE|url|http://www.jflex.de/^0|21|J|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

I usually go to the extent of writing a scanner specification file. A scanner, or "scanner generator" is essentially an optimized text parser. Since I usually work with Java my preferred method is JFlex (<a href="http://www.jflex.de" rel="nofollow noreferrer">http://www.jflex.de</a>), but there is also Lex, YACC, and several others.

Scanners work on regular expressions that you can define as macros. Then you implement callbacks when the regular expressions match part of the text.

When it comes to the code I have a specification file containing all the parsing logic. I run it through the scanner generator tool of choice to generate the source code in the language of choice. Then I just wrap all that into a parser function or class of some sort. This abstraction then makes it easy to manage all the regular expression logic, and it is very good performance. Of course, it is overkill if you are working with just one or two regexps, and it easily takes at least 2-3 days to learn what the hell is going on, but if you ever work with, say, 5 or 6 or 30 of them, it becomes a really nice feature and implementing parsing logic starts to only take minutes and they stay easy to maintain and easy to document.

blocks|key|3153665|text|问题不在于正则表达式本身，而在于它们被当作黑盒对待。与任何编程语言一样，可维护性更多地与编写和阅读它的人有关，而不是与语言本身有关。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3153666|使用正确的工具来完成这项工作也有很多可说的。在你对原文的评论中提到的例子中，正则表达式不是用来解析超文本标记语言的错误工具，在PerlMonks上经常提到这一点。如果您试图仅使用正则表达式以任何类似于一般方式的方式解析HTML，那么您最终将要么以一种不正确且脆弱的方式进行解析，要么编写一个可怕且不可维护的正则表达式，或者(很可能)两者兼而有之。|3153667|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The problem is not with the regexes themselves, but rather with their treatment as a black box. As with any programming language, maintainability has more to do with the person who wrote it and the person who reads it than with the language itself.

There's also a lot to be said for using the right tool for the job. In the example you mentioned in your comment to the original post, a regex is the wrong tool to use for parsing HTML, as is mentioned rather frequently over on PerlMonks. If you try to parse HTML in anything resembling a general manner using only a regex, then you're going to end up either doing it in an incorrect and fragile manner, writing a horrendous and unmaintainable monstrosity of a regex, or (most likely) both.

blocks|key|3153818|text|有很多方法可以使RegEx更易于维护。归根结底，这只是一种技术(好吗？)当涉及到主要(有时甚至是次要的)更改时，程序员必须学习。当没有真正优秀的专业人员时，没有人会因为他们复杂的语法而为他们操心。但它们在工作中速度快、结构紧凑、非常灵活。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3153819|对于.NET用户来说，"Linq+to+RegEx“库可能更糟糕，或者是"Readable+Regular+Expressions+Library”。这使得它们更容易维护，也更容易编写。我在自己的项目中使用了它们，我知道我用它们分析的html-sourcecode代码随时都可能改变。|offset|length|3153820|但请相信我:当你理解它们时，它们甚至可以取笑于你的写作和阅读。:)|3153821|entityMap|0|LINK|mutability|MUTABLE|url|http://weblogs.asp.net/rosherove/archive/2008/05/06/introducing-linq-to-regex.aspx|1|http://flimflan.com/blog/ReadableRegularExpressions.aspx^0|0|C|D|0|11|10|1|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]|$D|W|E|X|1|Y]]|A|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

There are a lot of possibilities to make RegEx more maintainable. In the end it's just a technique a (good?) programmer has to learn when it comes to major (or sometimes even minor) changes. When there weren't some really good pro's no one would bother with them because of their complex syntax. But they are fast, compact and very flexible in doing their job.

For .NET People there could be the "<a href="http://weblogs.asp.net/rosherove/archive/2008/05/06/introducing-linq-to-regex.aspx" rel="nofollow noreferrer">Linq to RegEx</a>" library worse a look or "<a href="http://flimflan.com/blog/ReadableRegularExpressions.aspx" rel="nofollow noreferrer">Readable Regular Expressions Library</a>". It makes them more easy to maintain and yet easier to write. I used both of them in own projects I knew the html-sourcecode I analysed with them could change anytime.

But trust me: When you cotton on to them they could even make fun to write and read. :)

blocks|key|363086|text|我总是把这个问题当作一个积木问题来处理。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|363087|您不能仅仅编写3000个字符的正则表达式，然后希望得到最好的结果。你写一堆小块，然后把它们加在一起。|363088|例如，要匹配URI，您需要协议、授权、子域、域、tld、路径、参数(至少)。其中一些是可选的！|363089|我确信你可以写一个怪物来处理它，但是写块并把它们加在一起会更容易。|363090|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I've always approached this issue as a building-block problem.

You don't just write some 3000 character regex and hope for the best. You write a bunch of small chunks that you add together.

For example, to match a URI, you have the protocol, authority, subdomain, domain, tld, path, arguments (at least). And some of these are optional!

I'm sure you could write one monster to handle it, but it's easier to write chunks and add them together.

blocks|key|3153848|text|如果您使用RegExs引入的新特性，则非常易于维护。我提到的特性是来自Perl+6的后端口特性。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|CODE|entityRanges|data|3153849|直接从复制的示例。|3153850|定义命名模式|3153851|一些正则表达式在几个地方使用相同的子模式。从Perl+5.10开始，可以在模式的某个部分中定义命名子模式，以便可以在模式中的任何位置按名称调用它们。这个定义组的语法模式是(?(DEFINE)(?<name>pattern)...)。命名模式的插入被写为(?&name)。|3153852|下面的示例使用前面介绍的浮点数模式演示了此功能。多次使用的三个子模式是可选符号、整数的数字序列和小数。模式末尾的DEFINE组包含它们的定义。注意，小数小数模式是我们可以重用整数模式的第一个位置。|3153853|/%5E
++(?&osg)\+*+(+(?&int)(?&dec)?+%7C+(?&dec)+)
++++++++(?:+[eE](?&osg)(?&int)+)?
+$
+(?(DEFINE)
+++++(?<osg>[-%2B]?)+++++++++#+optional+sign
+++++(?<int>\d%2B%2B)++++++++++#+integer
+++++(?<dec>\.(?&int))+++++#+decimal+fraction
+)
/x|code-block|syntax|javascript|3153854|entityMap^0|J|4|Z|6|0|0|0|2D|U|3I|8|0|1K|6|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@$9|W|A|X|B|C]|$9|Y|A|Z|B|D]]|E|@]|F|$]]|$1|G|3|H|5|6|7|10|8|@]|E|@]|F|$]]|$1|I|3|J|5|6|7|11|8|@]|E|@]|F|$]]|$1|K|3|L|5|6|7|12|8|@$9|13|A|14|B|D]|$9|15|A|16|B|D]]|E|@]|F|$]]|$1|M|3|N|5|6|7|17|8|@$9|18|A|19|B|D]]|E|@]|F|$]]|$1|O|3|P|5|Q|7|1A|8|@]|E|@]|F|$R|S]]|$1|T|3|-4|5|6|7|1B|8|@]|E|@]|F|$]]]|U|$]]

RegExs can be very maintainable, if you utilize new features introduced by <code>Perl 5.10</code>. The features I refer to are back-ported features from <code>Perl 6</code>.
Example copied directly from <a href="http://perldoc.perl.org/perlretut.html#Defining-named-patterns" rel="nofollow noreferrer">perlretut</a>.
<h3>Defining named patterns</h3>
Some regular expressions use identical subpatterns in several places. Starting with Perl 5.10, it is possible to define named subpatterns in a section of the pattern so that they can be called up by name anywhere in the pattern. This syntactic pattern for this definition group is <code>(?(DEFINE)(?&lt;name&gt;pattern)...)</code>. An insertion of a named pattern is written as <code>(?&amp;name)</code>.
The example below illustrates this feature using the pattern for floating point numbers that was presented earlier on. The three subpatterns that are used more than once are the optional sign, the digit sequence for an integer and the decimal fraction. The <code>DEFINE</code> group at the end of the pattern contains their definition. Notice that the decimal fraction pattern is the first place where we can reuse the integer pattern.
<pre><code>/^
 (?&amp;osg)\ * ( (?&amp;int)(?&amp;dec)? | (?&amp;dec) )
 (?: [eE](?&amp;osg)(?&amp;int) )?
 $
 (?(DEFINE)
 (?&lt;osg&gt;[-+]?) # optional sign
 (?&lt;int&gt;\d++) # integer
 (?&lt;dec&gt;\.(?&amp;int)) # decimal fraction
 )
/x
</code></pre>

blocks|key|3366800|text|我通常使用注释将正则表达式拆分成多个片段，然后将它们放在一起进行最后的推送。片段可以是子字符串或数组元素|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3366801|两个PHP+PCRE示例(具体或特定用途并不重要)：|3366802|1)
++$dktpat+=+'/%5E[%5Ea-z0-9]*'.+//+skip+any+initial+non-digits
++++'([a-z0-9]:)?'.+//+division+within+the+district
++++'(\d%2B)'.+//+year
++++'((-)%7C-?([a-z][a-z])-?)'.+//+type+of+court+if+any+-+cv,+bk,+etc.
++++'(\d%2B)'.+//+docket+sequence+number
++++'[%5E0-9]*$/i';+//+ignore+anything+after+the+sequence+number
++if+(preg_match($dktpat,$DocketID,$m))+{

2)
++++$pat=+array+(
++++++'Row'++++++++=>+'\s*(\d*)',
++++++'Parties'++++=>+'(.*)',
++++++'CourtID'++++=>+'<a[%5E>]*>([a-z]*)</a>',
++++++'CaseNo'+++++=>+'<a[%5E>]*>([a-z0-9:\-]*)</a>',
++++++'FirstFiled'+=>+'([0-9\/]*)',
++++++'NOS'++++++++=>+'(\d*)',
++++++'CaseClosed'+=>+'([0-9\/]*)',
++++++'CaseTitle'++=>+'(.*)',
++++);
++++//+wrap+terms+in+table+syntax
++++$pat+=+'#<tr>(<td[%5E>]*>'.
++++++implode('</td>)(</tr><tr>)?(<td[%5E>]*>',$pat).
++++++'</td>)</tr>#iUx';
++++if+(preg_match_all+($pat,$this->DocketText,$matches,+PREG_PATTERN_ORDER))|code-block|syntax|javascript|3366803|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I commonly split up the regex into pieces with comments, then put them all together for the final push. Pieces can be either substrings or array elements

Two PHP PCRE examples (specifics or the particular use are not important):

<pre><code>1)
 $dktpat = '/^[^a-z0-9]*'. // skip any initial non-digits
 '([a-z0-9]:)?'. // division within the district
 '(\d+)'. // year
 '((-)|-?([a-z][a-z])-?)'. // type of court if any - cv, bk, etc.
 '(\d+)'. // docket sequence number
 '[^0-9]*$/i'; // ignore anything after the sequence number
 if (preg_match($dktpat,$DocketID,$m)) {

2)
 $pat= array (
 'Row' =&gt; '\s*(\d*)',
 'Parties' =&gt; '(.*)',
 'CourtID' =&gt; '&lt;a[^&gt;]*&gt;([a-z]*)&lt;/a&gt;',
 'CaseNo' =&gt; '&lt;a[^&gt;]*&gt;([a-z0-9:\-]*)&lt;/a&gt;',
 'FirstFiled' =&gt; '([0-9\/]*)',
 'NOS' =&gt; '(\d*)',
 'CaseClosed' =&gt; '([0-9\/]*)',
 'CaseTitle' =&gt; '(.*)',
 );
 // wrap terms in table syntax
 $pat = '#&lt;tr&gt;(&lt;td[^&gt;]*&gt;'.
 implode('&lt;/td&gt;)(&lt;/tr&gt;&lt;tr&gt;)?(&lt;td[^&gt;]*&gt;',$pat).
 '&lt;/td&gt;)&lt;/tr&gt;#iUx';
 if (preg_match_all ($pat,$this-&gt;DocketText,$matches, PREG_PATTERN_ORDER))
</code></pre>

blocks|key|3366942|text|您的问题似乎与正则表达式本身无关，只涉及通常用于表达正则表达式的语法。在许多核心程序员中，这种语法已经被认为是非常简洁和强大的，但对于更长的正则表达式来说，它实际上是不可读和不可维护的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3366943|有些人已经提到了Perl中的“x”标志，它有一些帮助，但不是很多。|3366944|我很喜欢正则表达式，但不喜欢它的语法。如果能够从可读的、有意义的方法名构造一个正则表达式，那就太好了。例如，不使用下面的C#代码：|3366945|foreach+(var+match+in+Regex.Matches(input,+@"-?(?<number>\d%2B)"))
{
++++Console.WriteLine(match.Groups["number"].Value);
}|code-block|syntax|javascript|3366946|你可以写一些更冗长但更易读和更易维护的代码：|3366947|int+number+=+0;
Regex+r+=+Regex.Char('-').Optional().Then(
++++Regex.Digit().OneOrMore().Capture(c+=>+number+=+int.Parse(c))
);
foreach+(var+match+in+r.Matches(input))
{
++++Console.WriteLine(number);
}|3366948|这只是一个快速的想法；我知道还有其他与此无关的可维护性问题(尽管我认为这些问题很少，也更小)。这样做的一个额外好处是编译时验证。|3366949|当然，如果您认为这太过了并且过于冗长，您仍然可以使用介于两者之间的正则表达式语法，也许...|3366950|instead+of:+++-?(?<number>\d%2B)
could+have:+++("-"+or+"")+%2B+(number+=+digit+*+[1..])|3366951|这仍然是可读性的一百万倍，而且只有两倍的长度。这样的语法可以很容易地与普通正则表达式具有相同的表达能力，并且它当然可以集成到编程语言的编译器中进行静态分析。|3366952|我真的不知道为什么在重新思考整个编程语言(例如Perl6，或者C#是新的)的时候，也会有这么多人反对重新思考正则表达式的语法。此外，上述非常冗长的想法甚至与“旧的”正则表达式也不是不兼容的；API可以很容易地实现为在幕后构造旧式正则表达式的API。|3366953|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|13|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|14|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|15|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|16|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|17|8|@]|9|@]|A|$]]|$1|S|3|T|5|H|7|18|8|@]|9|@]|A|$I|J]]|$1|U|3|V|5|6|7|19|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|Z|$]]

Your question doesn’t seem to pertain to regular expressions themselves, but only the syntax generally used to express regular expressions. Among many hardcore coders, this syntax has come to be accepted as pretty succinct and powerful, but for longer regular expressions it is actually really unreadable and unmaintainable.

Some people have already mentioned the “x” flag in Perl, which helps a bit, but not much.

I like regular expressions a lot, but not the syntax. It would be nice to be able to construct a regular expression from readable, meaningful method names. For example, instead of this C# code:

<pre><code>foreach (var match in Regex.Matches(input, @"-?(?&lt;number&gt;\d+)"))
{
 Console.WriteLine(match.Groups["number"].Value);
}
</code></pre>

you could have something much more verbose but much more readable and maintainable:

<pre><code>int number = 0;
Regex r = Regex.Char('-').Optional().Then(
 Regex.Digit().OneOrMore().Capture(c =&gt; number = int.Parse(c))
);
foreach (var match in r.Matches(input))
{
 Console.WriteLine(number);
}
</code></pre>

This is just a quick idea; I know there are other, unrelated maintainability issues with this (although I would argue they are fewer and more minor). An extra benefit of this is compile-time verification.

Of course, if you think this is over the top and too verbose, you can still have a regular expression syntax that is somewhere in between, perhaps...

<pre><code>instead of: -?(?&lt;number&gt;\d+)
could have: ("-" or "") + (number = digit * [1..])
</code></pre>

This is still a million times more readable and only twice as long. Such a syntax can easily be made to have the same expressive power as normal regular expressions, and it can certainly be integrated into a programming language’s compiler for static analysis.

I don’t really know why there is so much opposition to rethinking the syntax for regular expressions even when entire programming languages are rethought (e.g. Perl 6, or when C# was new). Furthermore, the above very-verbose idea is not even incompatible with “old” regular expressions; the API could easily be implemented as one that constructs an old-style regular expression under the hood.

Any code I've seen that uses Regexes tends to use them as a black box:

<ol>
<li>Put in string</li>
<li>Magic Regex</li>
<li>Get out string</li>
</ol>

This doesn't seem a particularly good idea to use in production code, as even a small change can often result in a completely different regex.

Apart from cases where the standard is permanent and unchanging, are regexes the way to do things, or is it better to try different methods?

Are regexes really maintainable?

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

我见过的任何使用Regexes的代码都倾向于将它们用作黑盒：Put in stringMagic RegexGet out string在生产代码中使用这似乎不是一个特别好的主意，因为即使是很小的更改通常也会导致完全不同的正则表达式。除了标准是永久的和不变的情况外，正则表达式是做事情的方式，还是尝试不同的方法更好？

问正则表达式真的可维护吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问正则表达式真的可维护吗？EN