Düzenli ifadeler neden bu kadar tartışmalı? [kapalı]

Düzenli ifadeleri (başka bir deyişle RegEx-es olarak bilinir) keşfederken, düzenli ifadeleri Kutsal Kâse olarak gören birçok kişi vardır. Çok karmaşık görünen bir şey - herhangi bir sorunun cevabı olmalı. Her sorunun düzenli ifadeler kullanılarak çözülebileceğini düşünüyorlar.

Öte yandan, düzenli ifadelerden kaçınmaya çalışan birçok insan da var. Düzenli ifadeler etrafında bir yol bulmaya çalışırlar ve düzenli ifadeler daha kompakt bir çözüm olsa bile, sadece uğruna ek kodlamayı kabul ederler.

Düzenli ifadeler neden bu kadar tartışmalı kabul ediliyor? Nasıl çalıştıklarına dair yaygın yanlış anlaşılmalar var mı? Yoksa düzenli ifadelerin genellikle yavaş olduğuna dair geniş bir inanç olabilir mi?

İnsanların düzenli ifadelere karşı çıkmadıklarını düşünmüyorum, çünkü yavaşlar, ama okumak ve yazmak zor olduğu için doğru olmak zor. Düzenli ifadelerin soruna etkili ve kompakt bir çözüm sağladığı bazı durumlar olsa da, bazen okunması kolay, bakımı kolay bir kod bölümü kullanmanın daha iyi olduğu durumlara atılırlar.

Regexes'i Bakım Yapabilme

Daha önce “düzenli ifadeler” olarak adlandırılan örüntüleri belirsizleştirmeye yönelik büyük bir ilerleme Perl's /x bazen (?x)gömüldüğünde yazılan ve boşluk (satır kesmesi, girintileme) ve yorumlara izin veren işaretidir. Bu, okunabilirliği ve dolayısıyla sürdürülebilirliği ciddi şekilde geliştirir. Beyaz boşluk bilişsel parçalamaya izin verir, böylece hangi grupların neyle birlikte olduğunu görebilirsiniz.

Modern kalıplar artık hem nispeten sayılı hem de adlandırılmış geri başvuruları desteklemektedir. Bu, ihtiyacınız olduğunu anlamak için artık yakalama gruplarını saymanıza gerek olmadığı anlamına gelir$4 veya \7. Bu, diğer kalıplara eklenebilecek kalıplar oluştururken yardımcı olur.

Göreceli olarak numaralandırılmış bir yakalama grubuna örnek:

$ dupword = qr {\ b (?: (\ w +) (?: \ s + \ g {-1}) +) \ b} xi;
$ quoted = qr {(["']) $ dupword \ 1} x;

Ve burada adlandırılmış yakalamaların üstün yaklaşımının bir örneği:

$dupword = qr{ \b (?: (?<word> \w+ ) (?: \s+ \k<word> )+ ) \b }xi;
$quoted  = qr{ (?<quote> ["'] ) $dupword  \g{quote} }x;

Dilbilgisel Düzenlemeler

Hepsinden iyisi , bu adlandırılmış yakalamalar bir (?(DEFINE)...)blok içine yerleştirilebilir , böylece bildirimi kalıplarınızın tek tek adlandırılmış öğelerinin yürütülmesinden ayırabilirsiniz. Bu onları kalıptaki alt rutinler gibi hareket ettirir.
Bu tür “dilbilgisel regex” in iyi bir örneği bu cevapta ve bu cevapta bulunabilir . Bunlar daha çok gramer bildirisine benziyor.

İkincisinin size hatırlattığı gibi:

… Hiçbir zaman çizgi gürültüsü kalıpları yazmadığınızdan emin olun. Gerek yok ve gerek yok. Beyaz boşluk, yorumlar, alt rutinler veya alfasayısal tanımlayıcıları yasaklayan hiçbir programlama dili korunamaz. Öyleyse kalıplarınızdaki tüm bunları kullanın.

Bu fazla vurgulanamaz. Elbette bu şeyleri desenlerinizde kullanmazsanız, genellikle bir kabus yaratacaksınız. Eğer Ama eğer yapmak bunları kullanmak olsa da, sen gerekmez.

İşte modern bir gramer deseninin başka bir örneği, bu RFC 5322'yi ayrıştırmak için: 5.10.0 kullanın;

$rfc5322 = qr{

   (?(DEFINE)

     (?<address>         (?&mailbox) | (?&group))
     (?<mailbox>         (?&name_addr) | (?&addr_spec))
     (?<name_addr>       (?&display_name)? (?&angle_addr))
     (?<angle_addr>      (?&CFWS)? < (?&addr_spec) > (?&CFWS)?)
     (?<group>           (?&display_name) : (?:(?&mailbox_list) | (?&CFWS))? ; (?&CFWS)?)
     (?<display_name>    (?&phrase))
     (?<mailbox_list>    (?&mailbox) (?: , (?&mailbox))*)

     (?<addr_spec>       (?&local_part) \@ (?&domain))
     (?<local_part>      (?&dot_atom) | (?&quoted_string))
     (?<domain>          (?&dot_atom) | (?&domain_literal))
     (?<domain_literal>  (?&CFWS)? \[ (?: (?&FWS)? (?&dcontent))* (?&FWS)?
                                   \] (?&CFWS)?)
     (?<dcontent>        (?&dtext) | (?&quoted_pair))
     (?<dtext>           (?&NO_WS_CTL) | [\x21-\x5a\x5e-\x7e])

     (?<atext>           (?&ALPHA) | (?&DIGIT) | [!#\$%&'*+-/=?^_`{|}~])
     (?<atom>            (?&CFWS)? (?&atext)+ (?&CFWS)?)
     (?<dot_atom>        (?&CFWS)? (?&dot_atom_text) (?&CFWS)?)
     (?<dot_atom_text>   (?&atext)+ (?: \. (?&atext)+)*)

     (?<text>            [\x01-\x09\x0b\x0c\x0e-\x7f])
     (?<quoted_pair>     \\ (?&text))

     (?<qtext>           (?&NO_WS_CTL) | [\x21\x23-\x5b\x5d-\x7e])
     (?<qcontent>        (?&qtext) | (?&quoted_pair))
     (?<quoted_string>   (?&CFWS)? (?&DQUOTE) (?:(?&FWS)? (?&qcontent))*
                          (?&FWS)? (?&DQUOTE) (?&CFWS)?)

     (?<word>            (?&atom) | (?&quoted_string))
     (?<phrase>          (?&word)+)

     # Folding white space
     (?<FWS>             (?: (?&WSP)* (?&CRLF))? (?&WSP)+)
     (?<ctext>           (?&NO_WS_CTL) | [\x21-\x27\x2a-\x5b\x5d-\x7e])
     (?<ccontent>        (?&ctext) | (?&quoted_pair) | (?&comment))
     (?<comment>         \( (?: (?&FWS)? (?&ccontent))* (?&FWS)? \) )
     (?<CFWS>            (?: (?&FWS)? (?&comment))*
                         (?: (?:(?&FWS)? (?&comment)) | (?&FWS)))

     # No whitespace control
     (?<NO_WS_CTL>       [\x01-\x08\x0b\x0c\x0e-\x1f\x7f])

     (?<ALPHA>           [A-Za-z])
     (?<DIGIT>           [0-9])
     (?<CRLF>            \x0d \x0a)
     (?<DQUOTE>          ")
     (?<WSP>             [\x20\x09])
   )

   (?&address)

}x;

Bu olağanüstü ve muhteşem değil mi? BNF tarzı bir dilbilgisi alabilir ve temel yapısını kaybetmeden doğrudan koda çevirebilirsiniz!

Modern gramer desenleri hala sizin için yeterli değilse Damian Conway'in parlak Regexp::Grammarsmodülü , daha üstün hata ayıklama ile daha da temiz bir sözdizimi sunar. RFC 5322 recast'ı bu modüldeki bir desene ayrıştırmak için aynı kod:

#!/usr/bin/perl

use strict;
use warnings;
use 5.010;
use Data::Dumper "Dumper";

my $rfc5322 = do {
    use Regexp::Grammars;    # ...the magic is lexically scoped
    qr{

    # Keep the big stick handy, just in case...
    # <debug:on>

    # Match this...
    <address>

    # As defined by these...
    <token: address>         <mailbox> | <group>
    <token: mailbox>         <name_addr> | <addr_spec>
    <token: name_addr>       <display_name>? <angle_addr>
    <token: angle_addr>      <CFWS>? \< <addr_spec> \> <CFWS>?
    <token: group>           <display_name> : (?:<mailbox_list> | <CFWS>)? ; <CFWS>?
    <token: display_name>    <phrase>
    <token: mailbox_list>    <[mailbox]> ** (,)

    <token: addr_spec>       <local_part> \@ <domain>
    <token: local_part>      <dot_atom> | <quoted_string>
    <token: domain>          <dot_atom> | <domain_literal>
    <token: domain_literal>  <CFWS>? \[ (?: <FWS>? <[dcontent]>)* <FWS>?

    <token: dcontent>        <dtext> | <quoted_pair>
    <token: dtext>           <.NO_WS_CTL> | [\x21-\x5a\x5e-\x7e]

    <token: atext>           <.ALPHA> | <.DIGIT> | [!#\$%&'*+-/=?^_`{|}~]
    <token: atom>            <.CFWS>? <.atext>+ <.CFWS>?
    <token: dot_atom>        <.CFWS>? <.dot_atom_text> <.CFWS>?
    <token: dot_atom>        <.CFWS>? <.dot_atom_text> <.CFWS>?
    <token: dot_atom_text>   <.atext>+ (?: \. <.atext>+)*

    <token: text>            [\x01-\x09\x0b\x0c\x0e-\x7f]
    <token: quoted_pair>     \\ <.text>

    <token: qtext>           <.NO_WS_CTL> | [\x21\x23-\x5b\x5d-\x7e]
    <token: qcontent>        <.qtext> | <.quoted_pair>
    <token: quoted_string>   <.CFWS>? <.DQUOTE> (?:<.FWS>? <.qcontent>)*
                             <.FWS>? <.DQUOTE> <.CFWS>?

    <token: word>            <.atom> | <.quoted_string>
    <token: phrase>          <.word>+

    # Folding white space
    <token: FWS>             (?: <.WSP>* <.CRLF>)? <.WSP>+
    <token: ctext>           <.NO_WS_CTL> | [\x21-\x27\x2a-\x5b\x5d-\x7e]
    <token: ccontent>        <.ctext> | <.quoted_pair> | <.comment>
    <token: comment>         \( (?: <.FWS>? <.ccontent>)* <.FWS>? \)
    <token: CFWS>            (?: <.FWS>? <.comment>)*
                             (?: (?:<.FWS>? <.comment>) | <.FWS>)

    # No whitespace control
    <token: NO_WS_CTL>       [\x01-\x08\x0b\x0c\x0e-\x1f\x7f]

    <token: ALPHA>           [A-Za-z]
    <token: DIGIT>           [0-9]
    <token: CRLF>            \x0d \x0a
    <token: DQUOTE>          "
    <token: WSP>             [\x20\x09]

    }x;

};


while (my $input = <>) {
    if ($input =~ $rfc5322) {
        say Dumper \%/;       # ...the parse tree of any successful match
                              # appears in this punctuation variable
    }
}

Orada iyi bir sürü şey var perlre manpage ama temel regex tasarım özellikleri bu dramatik gelişmeler yalnız Perl ile sınırlı değillerdir. Gerçekten de pcrepattern manpage daha kolay okunabilir ve aynı bölgeyi kapsıyor olabilir.

Modern kalıpların, sonlu otomata sınıfınızda öğretilen ilkel şeylerle neredeyse hiçbir ortak yanı yoktur.

Regexes harika bir araç, ancak insanlar "Hey, ne harika bir araç, X yapmak için kullanacağım!" burada X, farklı bir aracın daha iyi olduğu bir şeydir (genellikle bir ayrıştırıcı). Bir tornavida problemine ihtiyacınız olan bir çekiç kullanarak standarttır.

Düzenli ifadeleri düzenli olarak (tanıma amaçlı) kullanan neredeyse tanıdığım herkes, RE'leri grep, sed, awk ve Perl gibi birinci sınıf programlama yapıları olarak gören araçları kullandıkları Unix-ish geçmişinden geliyor. Düzenli bir ifade kullanmak için neredeyse hiç sözdizimsel yük olmadığından, üretkenlikleri üretildiklerinde artar.

Buna karşılık, RE'lerin harici bir kütüphane olduğu dilleri kullanan programcılar, düzenli ifadelerin tabloya getirebileceği düşünme eğilimindedir. Programcı "zaman maliyeti" o kadar yüksektir ki a) RE'ler asla eğitimlerinin bir parçası olarak ortaya çıkmazlar veya b) RE'ler açısından "düşünmezler" ve daha tanıdık kalıplara geri dönmeyi tercih ederler.

Düzenli ifadeler, bir dizi girişi işlemek için özel bir sonlu durum makinesi (FSM) yazmanızı sağlar. Normal ifadeleri kullanmanın zor olmasının en az iki nedeni vardır:

• Eski yazılım geliştirme, çok fazla planlama, kağıt model ve dikkatli düşünmeyi içerir. Düzenli ifadeler bu modele çok iyi uyum sağlar, çünkü etkili bir ifade yazmak için FSM'nin yollarını görselleştirerek ona çok fazla bakmak gerekir.

  Modern yazılım geliştiricileri kodun daha çok kullanılmasını ve kodun doğru olup olmadığını görmek için bir hata ayıklayıcı kullanırlar. Düzenli ifadeler bu çalışma tarzını çok iyi desteklemiyor. Düzenli bir ifadenin "çalışması" etkili bir şekilde atomik bir işlemdir. Bir hata ayıklayıcıda adım adım yürütmeyi gözlemlemek zor.

• Yanlışlıkla düşündüğünüzden daha fazla girdi kabul eden normal bir ifade yazmak çok kolaydır. Normal ifadenin değeri gerçekten geçerli girdiyle eşleşmez, geçersiz girdiyle eşleşmez . Düzenli ifadeler için "negatif testler" yapma teknikleri çok ileri değildir veya en azından yaygın olarak kullanılmamaktadır.

  Bu, düzenli ifadelerin okunması zor olan noktaya gider. Sadece düzenli bir ifadeye bakarak, reddedilmesi gereken, ancak yanlışlıkla kabul edilen tüm olası girdileri görselleştirmek çok yoğun bir konsantrasyon gerektirir. Hiç başkasının normal ifade kodunda hata ayıklamaya çalıştınız mı?

Bugün yazılım geliştiricileri arasında düzenli ifadelerin kullanılmasına karşı bir direnç varsa, bunun esas olarak bu iki faktörden kaynaklandığını düşünüyorum.

İnsanlar düzenli ifadelerin zor olduğunu düşünüyorlar; ama bunun sebebi onları yanlış kullanıyorlar. Yorum içermeyen karmaşık tek satırlar yazma, girintiler veya adlandırılmış yakalamalar. (Karmaşık SQL ifadenizi yorum, girinti veya takma ad olmadan tek bir satırda sıkıştırmazsınız, değil mi?). Evet, birçok insan için mantıklı değil.

İşiniz varsa Ancak, herhangi bir şey (... Orada kabaca herhangi bir web uygulaması) metin ayrıştırma ile ilgisi ve düzenli ifade bilmiyorum işinizde emmek ve kendi zamanını boşa harcıyorsun ve o senin işveren. Onlar hakkında bilmeniz gereken her şeyi ve daha fazlasını öğretmek için mükemmel kaynaklar var.

Yaygın olarak kabul edilen IDE'lerde en popüler öğrenme aracından yoksun oldukları için: Regex Sihirbazı yoktur. Otomatik Tamamlama bile değil. Her şeyi kendiniz kodlamanız gerekiyor.

" Düzenli İfadeler: Artık İki Sorununuz Var " Jeff Atwood'un bu konuyla ilgili harika bir makalesi. Temel olarak, düzenli ifadeler "zor"! Yeni sorunlar yaratabilirler. Ancak etkilidirler.

Onların bu kadar tartışmalı olduklarını sanmıyorum.

Ben de kendi sorunuzu cevapladığınızı düşünüyorum, çünkü onları her yerde kullanmanın ne kadar aptalca olduğuna dikkat çekiyorsunuz ( Her şey normal bir dil değildir 2 ) veya bunları kullanmaktan kaçınmaktır. Programcı olarak, düzenli ifadelerin koda ne zaman yardım edeceği veya ona zarar vereceği konusunda akıllıca bir karar vermelisiniz. Böyle bir kararla karşı karşıya kaldığında, akılda tutulması gereken iki önemli şey, sürdürülebilirlik (okunabilirliği ima eder) ve genişletilebilirliktir.

Onlara özellikle karşı olanlar için, tahminimce onları düzgün kullanmayı asla öğrenmediler. Bence iyi bir eğitici ile sadece birkaç saat geçiren çoğu kişi onları anlayacak ve çok hızlı akıcı olacak. İşte nereden başlayacağımla ilgili önerim:

http://docs.python.org/howto/regex

Bu sayfa Python bağlamındaki düzenli ifadelerden bahsediyor olsa da, bilgilerin başka yerlerde çok uygulanabilir olduğunu gördüm. Python'a özgü birkaç şey var, ancak açıkça belirtildiğine ve hatırlanması kolay olduğuna inanıyorum.

Düzenli ifadeler, aritmetik işleçlerin sayılara ne olduğunu dizelerdir ve bunları tartışmalı olarak kabul etmem. Kendim gibi oldukça militan bir OO aktivisti bile (dizeler üzerinde diğer nesneleri seçme eğilimi gösteren) bile onları reddetmek için zor olurdu.

Sorun şu ki, normal ifadeler potansiyel olarak o kadar güçlüdür ki onlarla birlikte farklı şeyler kullanmanız gerekir.

İyi bir programcı nerede kullanılacağını ve nerede kullanılamayacağını bilmelidir. Tipik örnek, normal olmayan dilleri ayrıştırmaktır (bkz. Bir dilin normal olup olmadığına karar verme ).

İlk başta kendinizi gerçek düzenli ifadelerle (uzantısız) kısıtlarsanız yanlış gidemeyeceğinizi düşünüyorum . Bazı uzantılar hayatınızı biraz daha kolaylaştırabilir, ancak gerçek bir normal ifade olarak ifade edilmesi zor bir şey bulursanız , bu normal ifadenin doğru araç olmadığının bir göstergesi olabilir.

Neredeyse goto'ların neden tartışmalı olduğunu soruyor olabilirsiniz.

Temel olarak, çok "bariz" bir güç elde ettiğinizde, insanlar en iyi seçenek olmadığı durumlar için onları kötüye kullanmaya eğilimlidirler. CSV'leri veya XML veya HTML'yi normal ifadelerde ayrıştırmak isteyen kişi sayısı, örneğin beni hayrete düşürüyor. Bu iş için yanlış araç. Ancak bazı kullanıcılar zaten regexes kullanmakta ısrar ediyorlar.

Şahsen, mutlu ortamı bulmaya çalışıyorum - iyi oldukları şey için normal ifadeler kullanın ve optimalden daha az olduklarında onlardan kaçının.

Normal ifadelerin CSV'leri, XML, HTML vb. Ayrıştırmak için hala kullanılabileceğini unutmayın. Ancak genellikle tek bir normal ifadede kullanılamaz.

"Tartışmalı" kelimesinin doğru kelime olduğunu sanmıyorum.

Ama insanların "böyle ve böyle bir dize manipülasyonu yapmak için ihtiyacım olan düzenli ifade nedir?" Dediği tonlarca örnek gördüm. bunlar XY problemleridir.

Başka bir deyişle, regex'in ihtiyaç duydukları şey olduğu varsayımından yola çıkmışlardı, ancak bir split (), perl'in tr /// gibi karakterlerin diğeriyle değiştirildiği bir çeviri ile daha iyi olurdu veya sadece bir dizin ().

Bu ilginç bir konu.
Birçok normal ifade meraklısı, formülün kısalığı verimlilikle karıştırıyor gibi görünüyor.
Bunun da ötesinde, çok fazla düşünce gerektiren bir regexp, yazarına, onu meşru kılan büyük bir memnuniyet yaratır.

Ancak ... regexps, performans bir sorun olmadığında ve örneğin Perl'de bir metin çıktısıyla hızlı bir şekilde ilgilenmeniz gerektiğinde çok uygundur. Ayrıca, aynı zamanda performans olduğunu bir sorun sadece bir arabası ya da daha az verimli olabilecek bir ev yapımı algoritma kullanarak regexp'in kütüphanesini yenmek için denemek için tercih edebilirsiniz.

Ayrıca, normal ifadelerin haksız yere eleştirilmesinin birkaç nedeni vardır.

• regexp verimli değil, çünkü en iyiyi oluşturmak belli değil
• bazı programcılar birçok kez kullanılacak bir normal ifadeyi yalnızca bir kez derlemeyi "unutur" (Java'daki statik bir Desen gibi)
• bazı programcılar deneme yanılma stratejisine - regexps ile daha da az çalışır!

Bence Regex'i Öğrenme ve regex'i popüler olmayan bir şekilde sürdürme, geliştiricilerin çoğu tembel ya da çoğu kendileri için ayrıştırma yapmak için harici kütüphanelere güveniyorlar ... cevap için google'a güveniyorlar ve hatta forumlarda soruyorlar sorunları için tam kod. Ancak bir normal ifadeyi uygulamak veya değiştirmek / korumak söz konusu olduğunda başarısız olurlar.

"Arkadaşların HTML'yi Ayrıştırmak için Regex'i kullanmasına izin verme"

Ama endişelendiğim kadarıyla Regex kullanarak tam HTML ayrıştırıcılar yaptım ve ben kendi regex html dizeleri hem hızlı hem de bellek açısından ayrıştırmada daha iyi olduğunu buluyorum (eğer bir Fikir varsa ne elde etmek için :))

Düzenli ifadeler, ben dahil birçok insan için ciddi bir gizemdir. Harika çalışıyor ama matematik denklemine bakmak gibi. Birinin nihayet http://regexlib.com/ adresinde çeşitli düzenli ifade işlevlerinin birleştirilmiş bir konumunu oluşturduğunu bildirmekten memnuniyet duyuyorum . Şimdi Microsoft, yalnızca harfleri ortadan kaldırmak veya tarihleri ​​filtrelemek gibi sık kullanılan şeylerin çoğunu otomatik olarak yapacak normal bir ifade sınıfı oluşturacaksa.

Düzenli ifadeleri zaman zaman çok değerli buluyorum. Bazı "bulanık" aramalar yapmam gerektiğinde ve belki de yerine geçer. Veriler ne zaman değişebilir ve belirli bir rastgele olabilir. Ancak, basit bir arama yapmak ve değiştirmek veya bir dize kontrol etmek gerektiğinde, düzenli ifadeler kullanmıyorum. Her ne kadar tanıyan birçok insan tanıyorsam da, her şey için kullanıyorlar. Bu tartışma.

Duvara çakmak istiyorsanız, çekiç kullanmayın. Evet, işe yarayacak, ancak çekiç aldığınız zaman duvara 20 çiviyi koyabilirim.

Düzenli ifadeler, tasarlandıkları şey için kullanılmalı ve daha azı kullanılmamalıdır.

Normal ifadelerin önemli bir araç olduğunu düşünmeme rağmen, onlar hakkında en sinir bozucu şey farklı uygulamalar olmasıdır. Sözdizimi, değiştiriciler ve -özellikle- açgözlülükteki küçük farklılıklar, işleri gerçekten kaotik hale getirebilir, deneme yanılma gerektirebilir ve bazen şaşırtıcı hatalar üretebilir.

Bazı durumlarda bunları kullanmanız gerektiğini düşünüyorum. Örneğin bir lexer oluşturmak için.

Benim düşünceme göre, bu normal ifade yazabilen ve yazmayan (ya da neredeyse hiç) olmayan kişilerin bakış açısıdır. Ben kişisel bir şey bu örneğin, bir uyarının giriş geçerli, kullanıcı uyarmak için javascript, ya da sunucu tarafı dilde iyi bir düşünmek olduğunu.

Programcılar arasında daha az bilinen bir teknik olduğunu düşünüyorum. Yani, geniş bir kabul görmüyor. Kodunuzu incelemek veya çalışmanızı gözden geçirmek için teknik olmayan bir yöneticiniz varsa, düzenli bir ifade çok kötüdür. Mükemmel bir düzenli ifade yazmak için saatler harcayacaksınız ve modülün bu kadar az kod satırı yazdığını düşünmesi için birkaç not alacaksınız. Ayrıca, başka bir yerde söylendiği gibi, düzenli ifadeleri okumak çok zor bir iştir.

Derleyici tanımı için lex ve yacc'de kullanılan gibi düzenli düzenli ifade sistemleri iyi, çok kullanışlı ve temizdir. Bu sistemlerde, ifade türleri diğerleri açısından tanımlanır. 'Tartışmalı' (çöp) olan perl ve sed kodlarında (vb.) Yaygın olarak bulunan iğrenç, hatalı biçimlendirilmiş okunamayan hat gürültüsü devi tek katmanlı düzenli ifadelerdir.

Normal ifade için en geçerli ve normal kullanım, e-posta adresi biçimi doğrulamasıdır.

Bu iyi bir uygulama.

Düz dosyaları masaj, csv dosyaları oluşturmak, SQL ekleme deyimleri ve bu tür bir şey oluşturmak için TextPad bir kerelik olarak düzenli ifadeler sayısız kez kullandım.

İyi yazılmış düzenli ifadeler çok yavaş olmamalıdır. Genellikle, tonlarca Değiştir çağrısı gibi alternatifler çok daha yavaş seçeneklerdir. Tek geçişte de yapabilir.

Birçok durum tam olarak düzenli ifadeler gerektirir ve başka hiçbir şey gerektirmez.

Özel, yazdırılmayan karakterlerin zararsız karakterlerle değiştirilmesi de iyi bir kullanımdır.

Tabii ki, sürdürülebilirliğin zararına düzenli ifadeleri aşırı kullanan bazı kod tabanları olduğunu hayal edebiliyorum. Bunu hiç görmedim. Aslında yeterince düzenli ifadeler kullanmadığınız için kod yorumcular tarafından eschewed.