Güçlerini kaybetmeden düzenli ifadeler okunabilir mi?

Birçok programcı, hızlı bir düzenli ifade ifade etmenin, bugünlerde genellikle bazı web servislerinin yardımı ile veya daha geleneksel olarak etkileşimli bilgi isteminde veya belki de geliştirilmekte olan normal ifadeleri içeren küçük bir senaryo yazması ve bir test senaryoları koleksiyonu yazmanın mutluluğunu bilir. . Her iki durumda da işlem yinelemeli ve oldukça hızlıdır: İstediğinizle eşleşip yakalayana ve istemediğiniz şeyi reddedinceye kadar şifreli görünümlü dizgiyi hacklemeye devam edin.

Basit bir vaka için, bir Java regexp olarak, böyle bir şey olabilir:

Pattern re = Pattern.compile(
  "^\\s*(?:(?:([\\d]+)\\s*:\\s*)?(?:([\\d]+)\\s*:\\s*))?([\\d]+)(?:\\s*[.,]\\s*([0-9]+))?\\s*$"
);

Ayrıca pek çok programcı normal bir ifadeyi düzenlemeye ihtiyaç duymanın acısını ya da sadece eski bir kod tabanında düzenli bir ifadeyi kodlama zorunluluğunu bilir. Bölmek için biraz düzenleme yapıldığında, yukarıdaki regexp, regexps'e oldukça aşina olan herhangi birisini anlamak için hala çok kolaydır ve regexp ustaları ne yaptığını hemen görmelidir (bir kişinin egzersiz istemesi durumunda cevap vermelidir). kendileri bulmaktan.

Ancak, bir regexp'in gerçekten salt yazılabilir bir şey haline gelmesi için çok daha karmaşık hale gelmesi gerekmiyor ve hatta gayretli belgelerle ( elbette ki herkes yazdıkları tüm karmaşık regexps'ler için ...), regexps'i değiştirmek bir hale geliyor zor bir görev. Eğer regexp dikkatli bir şekilde test edilmediyse, bu çok tehlikeli bir görev olabilir (ama elbette herkes hem pozitif hem de negatif tüm karmaşık regexps için kapsamlı birim testlerine sahiptir).

Öyleyse, uzun lafın kısası, güçlerini kaybetmeden düzenli ifadeler için yazma-okuma çözümü / alternatif var mı? Yukarıdaki regexp alternatif bir yaklaşımla nasıl görünür? Çok dilli bir çözüm en iyisi olsa da, herhangi bir dilde sorun yoktur, ancak regexps çok dillidir.

Ve sonra, önceki regexp'nin yaptığı şey şudur: 1:2:3.4Boşluklara izin verilen ve sadece 3gerekli olan her sayıyı yakalayan , biçimindeki bir sayı dizisini ayrıştırma .

Küçük parçalardan oluşan bir takım insanlar bahsetti, ancak henüz hiç kimse bir örnek vermedi, işte benimki:

string number = "(\\d+)";
string unit = "(?:" + number + "\\s*:\\s*)";
string optionalDecimal = "(?:\\s*[.,]\\s*" + number + ")?";

Pattern re = Pattern.compile(
  "^\\s*(?:" + unit + "?" + unit + ")?" + number + optionalDecimal + "\\s*$"
);

En okunabilir değil, ama orijinalinden daha net olduğunu düşünüyorum.

Ayrıca, C # @kelimenin tam anlamıyla alınması gerektiğini (kaçış karakterleri yok) belirtmek için bir dizgeye hazırlanabilen işleci vardır number.@"([\d]+)";

Normal ifadeyi belgelemenin anahtarı onu belgelemektir. Çok sıklıkla insanlar hat gürültüsü gibi görünüp atıyorlar ve buna bırakıyorlar.

İçinde Perl/x normal ifadenin sonunda operatör normal ifadeyi belgelemek için izin boşluk bastırır.

Yukarıdaki normal ifade, şöyle olur:

$re = qr/
  ^\s*
  (?:
    (?:       
      ([\d]+)\s*:\s*
    )?
    (?:
      ([\d]+)\s*:\s*
    )
  )?
  ([\d]+)
  (?:
    \s*[.,]\s*([\d]+)
  )?
  \s*$
/x;

Evet, çok fazla okunabilirlikten ödün vermeden onu kısaltabilmesine rağmen, biraz dikey dikey boşluk tüketiyor.

Ve sonra, önceki regexp'nin yaptığı şey şudur: 1: 2: 3.4 formatındaki bir sayı dizisini ayrıştırmak, her sayıyı yakalamak, boşluklara izin verilen ve sadece 3 gerekli olan.

Bu düzenli ifadeye bakıldığında, nasıl çalıştığını (ve çalışmadığını) görebilirsiniz. Bu durumda, bu regex dizeyle eşleşir 1.

Diğer dillerde de benzer yaklaşımlar alınabilir. Python re.VERBOSE seçeneği orada çalışıyor.

Perl6 (yukarıdaki örnek perl5'tir) bunu PCRE'den daha güçlü yapılara götüren kurallar kavramı ile daha da ileri götürür (normal ve genişletilmiş düzenli olanlardan daha başka gramerlere (bağlamsız ve içeriğe duyarlı) erişim sağlar).

Java'da (bu örneğin nereden çizildiği), regex'i oluşturmak için dize birleştirmeyi kullanabilirsiniz.

Pattern re = Pattern.compile(
  "^\\s*"+
  "(?:"+
    "(?:"+
      "([\\d]+)\\s*:\\s*"+  // Capture group #1
    ")?"+
    "(?:"+
      "([\\d]+)\\s*:\\s*"+  // Capture group #2
    ")"+
  ")?"+ // First groups match 0 or 1 times
  "([\\d]+)"+ // Capture group #3
  "(?:\\s*[.,]\\s*([0-9]+))?"+ // Capture group #4 (0 or 1 times)
  "\\s*$"
);

Kuşkusuz, bu durum "muhtemelen bazı karışıklıklara yol açan dizgede daha fazla şey yaratıyor , daha kolay okunabiliyor (özellikle çoğu IDE'yi vurgulayan sözdizimi ile) ve belgelenebiliyor.

Anahtar, gücü tanımak ve düzenli ifadelerin sık sık içine girdiği doğayı "bir kez yaz" dır. Savunmaktan kaçınmak için kod yazmak, böylece normal ifade açık ve anlaşılabilir kalmaya devam eder. Java kodunu netlik için biçimlendiririz - dil size bunu yapma seçeneği verdiğinde normal ifadeler farklı değildir.

Bazı diller ve kütüphaneler tarafından sunulan "ayrıntılı" mod, bu endişelerin cevaplarından biridir. Bu modda, regexp dizesindeki boşluk bırakılır (kullanmanız gerekir \s) ve yorumlar mümkündür. İşte Python'da bunu varsayılan olarak destekleyen kısa bir örnek :

email_regex = re.compile(r"""
    ([\w\.\+]+) # username (captured)
    @
    \w+         # minimal viable domain part
    (?:\.w+)    # rest of the domain, after first dot
""", re.VERBOSE)

Olmaması gereken herhangi bir dilde, ayrıntılı bir terimden "normal" moda bir tercüman uygulamak basit bir görev olmalıdır. Regexps'inizin okunabilirliği konusunda endişeleriniz varsa, muhtemelen bu zaman yatırımını kolayca haklı çıkarırsınız.

Düzenli ifadeler kullanan her dil, okumayı kolaylaştırmak için bunları daha basit bloklardan oluşturmanıza olanak tanır ve örneğinizden daha karmaşık (ya da karmaşık) herhangi bir şeyle, kesinlikle bu seçenekten yararlanmalısınız. Java ve diğer pek çok dille ilgili özel sorun, normal ifadeleri "birinci sınıf" vatandaşlar olarak görmüyorlar, bunun yerine dize değişmezleri aracılığıyla dile gizlice girmelerini istiyorlar. Bu, aslında regex sözdiziminin bir parçası olmayan ve bir şeyleri okumayı zorlaştıran birçok tırnak işareti ve ters eğik çizgi anlamına gelir ve ayrıca kendi mini dilinizi ve tercümanınızı etkili bir şekilde tanımlamadan bundan daha okunaklı olamayacağınız anlamına gelir.

Düzenli ifadeleri birleştirmenin prototipik daha iyi yolu elbette beyazlık seçeneği ve regex-quoting operatörleri ile Perl'di. Perl 6, regex oluşturma kavramını, parçalardan gerçek özyinelemeli gramerlere kadar genişletir; bu, kullanımı gerçekten çok daha iyidir, hiçbir şekilde kıyaslama yapmaz. Dil, zaman teknesini kaçırmış olabilir, ancak regex desteği The Good Stuff (tm) idi.

Expresso'yu kullanmayı seviyorum: http://www.ultrapico.com/Expresso.htm

Bu ücretsiz uygulama zamanla faydalı bulduğum aşağıdaki özelliklere sahip:

• Regex'inizi kopyalayıp yapıştırabilirsiniz ve uygulama sizin için ayrıştırır.
• Regex'iniz yazıldığında, doğrudan uygulamadan test edebilirsiniz (uygulama size yakalamaların, değiştirmelerin listesini verecektir ...)
• Test ettikten sonra, uygulamak için C # kodunu üretecektir (kodun regex'inizin açıklamalarını içereceğini unutmayın).

Örneğin, az önce gönderdiğiniz regex ile şöyle görünürdü:

Tabii ki, bir deneyin, onu anlatan bin kelimeye değer. Lütfen bu uygulamanın editörüyle herhangi bir şekilde ilgili olduğumu not etmeyi de unutmayın.

Bazı şeyler için, sadece BNF gibi bir gramer kullanmak yardımcı olabilir. Bunları okumak normal ifadelerden çok daha kolay olabilir. GoldParser Builder gibi bir araç, dilbilgisini sizin için ağır olan bir çözümleyiciye dönüştürebilir.

BNF, EBNF, vb. Gramerleri okumak ve yapmak karmaşık bir normal ifadeden çok daha kolay olabilir. ALTIN ​​böyle şeyler için bir araçtır.

Aşağıdaki c2 wiki bağlantısı, üzerinde tartışmalar da dahil olmak üzere googled olabilecek olası alternatiflerin bir listesine sahiptir. Temel olarak gramer motor tavsiyemi tamamlayan bir "ayrıca bakınız" bağlantısı:

Normal İfadelere Alternatifler

"Farklı sözdizimine sahip semantik olarak eşdeğer bir tesis" anlamına "alternatif" alarak, en azından RegularExpressions ile / işaretli alternatifler var:

• Temel düzenli ifadeler
• "Genişletilmiş" normal ifadeler
• Perl uyumlu normal ifadeler
• ... ve diğer birçok değişken ...
• SNOBOL tarzı RE sözdizimi (SnobolLanguage, IconLanguage)
• SRE sözdizimi (EssExpressions olarak RE'ler)
• farklı FSM senkronizasyonları
• Sonlu durumlu kesişme gramerleri (oldukça etkileyici)
• AyrıştırmaExpressionGrammars, OMetaLanguage ve LuaLanguage'de olduğu gibi ( http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html )
• RebolLanguage'ın ayrıştırma modu
• ProbabilityBasedParsing ...

Bu eski bir sorudur ve Sözel İfadelerden hiç bahsetmedim, bu yüzden bu bilgiyi gelecekteki arayanlar için buraya ekleyeceğimi düşündüm. Sözlü İfadeler, regex'in anlamını öğrenmek zorunda kalmadan regex'in insan tarafından anlaşılabilir olmasını sağlamak için özel olarak tasarlanmıştır. Aşağıdaki örneğe bakınız. Bence bu istediğin şeyi en iyisini yapıyor.

// Create an example of how to test for correctly formed URLs
var tester = VerEx()
    .startOfLine()
    .then('http')
    .maybe('s')
    .then('://')
    .maybe('www.')
    .anythingBut(' ')
    .endOfLine();

// Create an example URL
var testMe = 'https://www.google.com';

// Use RegExp object's native test() function
if (tester.test(testMe)) {
    alert('We have a correct URL '); // This output will fire}
} else {
    alert('The URL is incorrect');
}

console.log(tester); // Outputs the actual expression used: /^(http)(s)?(\:\/\/)(www\.)?([^\ ]*)$/

Bu örnek javascript içindir, birçok programlama dili için bu kütüphaneyi şimdi bulabilirsiniz .

Basit yolu hala normal ifadeler kullanabilirsiniz ama açıklayıcı isimlerle daha basit expresssions oluştururken adresinin ifadesini inşa etmek olurdu mesela http://www.martinfowler.com/bliki/ComposedRegex.html (ve evet bu dize concat dan)

Ancak alternatif olarak, size tam özyinelemeli bir çözümleyici verecek, http://jparsec.codehaus.org/ gibi bir ayrıştırıcı birleştirici kitaplığı da kullanabilirsiniz . yine buradaki gerçek güç, kompozisyondan gelir (bu zaman işlevsel kompozisyon).

Bunun logstash en kayda değer olacağını düşündü grok ifadeleri. Grok, kısa olanlardan uzun ayrıştırma ifadeleri oluşturma fikri üzerine kuruludur. Bu yapı taşlarının uygun şekilde test edilmesini sağlar ve 100'ün üzerinde yaygın kullanılan desenle önceden paketlenmiş olarak gelir . Bu kalıplar dışında, tüm düzenli ifadelerin sözdiziminin kullanılmasına izin verir.

Grok olarak ifade edilen yukarıdaki örnek şudur: ( Hata ayıklayıcı uygulamasında test ettim ancak ağartılmış olabilir):

"(( *%{NUMBER:a} *:)? *%{NUMBER:b} *:)? *%{NUMBER:c} *(. *%{NUMBER:d} *)?"

İsteğe bağlı parçalar ve boşluklar normalden biraz çirkin görünmesine neden olur, ancak hem burada hem de diğer durumlarda grok kullanarak birinin hayatı daha güzel olabilir.

F # 'da FsVerbalExpressions modülüne sahipsiniz . Regex'leri sözlü ifadelerden oluşturmanıza olanak sağlar, ayrıca önceden oluşturulmuş regex'leri (URL gibi) de vardır.

Bu sözdizimi için örneklerden biri şudur:

let groupName =  "GroupNumber"

VerbEx()
|> add "COD"
|> beginCaptureNamed groupName
|> any "0-9"
|> repeatPrevious 3
|> endCapture
|> then' "END"
|> capture "COD123END" groupName
|> printfn "%s"

// 123

F # sözdizimini bilmiyorsanız, groupName "GroupNumber" dizesidir.

Sonra "COD (? <GroupNumber> [0-9] {3}) END" olarak oluşturdukları bir Sözlü Anlatım (VerbEx) oluştururlar. Daha sonra "COD123END" dizisinde test ettiler, burada "GroupNumber" adlı yakalama grubunu elde ettiler. Bu 123 ile sonuçlanır.

Dürüst olmak gerekirse normal regex'i anlamak daha kolay.

İlk önce, sadece çalışan kodun kötü kod olduğunu anlayın. İyi kod aynı zamanda karşılaşılan hataları doğru olarak bildirmelidir.

Örneğin, bir kullanıcının hesabından başka bir kullanıcının hesabına para transfer etmek için bir işlev yazıyorsanız; sadece "çalışmış veya başarısız" bir boolean döndürmezsiniz, çünkü bu arayan kişiye neyin yanlış gittiği hakkında bir fikir vermez ve arayan kişinin kullanıcıyı doğru şekilde bilgilendirmesine izin vermez. Bunun yerine, bir dizi hata kodunuz (veya bir takım istisnalar) olabilir: hedef hesap bulamadınız, kaynak hesapta yetersiz bakiye, izin reddedildi, veritabanına bağlanamıyorum, çok fazla yükleme (daha sonra tekrar deneyin), vb. .

Şimdi "1: 2: 3.4 biçimindeki bir sayı dizisini ayrıştırma" örneğinizi düşünün. Tüm regex, kullanıcıya yeterli geri bildirimin sunulmasına izin vermeyen bir "pass / fail" i bildirir (bu geri bildirimin bir günlükteki bir hata mesajı olup olmadığı veya hataların kırmızı olarak gösterildiği etkileşimli bir GUI) kullanıcı tipleri veya başka bir şey). Hangi tür hataları doğru şekilde tanımlayamıyor? İlk sayıdaki hatalı karakter, ilk sayı çok büyük, ilk sayıdan sonra kaybolan kolon vb.

"Yalnızca işe yarayan hatalı kodu" yeterince açıklayıcı hatalar sağlayan iyi bir koda dönüştürmek "için regex'i birçok küçük regex'e ayırmanız gerekir (tipik olarak, regex'leri ilk etapta regexler olmadan yapması daha kolay olan küçük regexler ).

Kodu okunabilir / sürdürülebilir hale getirmek, kodu iyi hale getirmenin yalnızca tesadüfi bir sonucudur.