Co was najbardziej wkurza z pracą z wyrażeniami regularnymi?

1
  • Wyrażenia na 40 znaków w kodzie? if($postcode =~ s/^([a-zA-Z]{1,2}\d{1}(|[a-zA-Z0-9]{1}))(|\s+)\d{1}\w{2}$/$1/)
  • Brak sensownego API/doc'ów do funkcji
  • Konieczność sprawdzania flag/elementów regexpów w necie?
  • Błędy (backtracking, jit, utf8, recursive patterns)
  • Więcej..?

Piszcie, co was wkurza, czemu z nich nie korzystacie?

(Pytanie oczywiście na potrzeby libki t-regx).

1

Nie, dokumentacja to nie. Ta na MDN jest wystarczająco dobra.

Nieczytelność przy długich wyrażeniach. Dlatego regexy stosuję tylko jak są proste, a jak trzeba coś bardziej złożonego napisać to wrzucam w projekt verbal expressions i da się żyć.

6

Oprócz tego co wymieniłeś

  • niespójności między implementacjami regexpów w różnych językach, narzędziach itd. Nawet znalazłem jakiś artykulik o tym :D
  • brzydka, nieprzyjemna składnia - wyrażenia na 40+ znaków nie byłyby problemem, gdyby nie były jakimś paskudnym plątańcem kilku rodzajów nawiasów, ukośników i innych znaków specjalnych ściśniętych do kupy tak, że oczy bolą od samego patrzenia...

Ogólnie to regexów w kodzie prawie nie używam, chyba że do jakiegoś prostego input validation typu nie wiem, "czy PESEL wygląda jak PESEL". Poza kodem używam czasem przy przeszukiwaniu kodu / logów / rzeczy w tym stylu. Czasem nawet zmiany w kodzie robię regexpami, jeśli coś byłoby zbyt upierdliwe by robić na piechotę, a IDE akurat czegoś nie ogarnie.

1

W tym przypadku wkurza mnie:

  • bezsensowne {1} w wielu miejscach
  • jeśli dobrze widzę, to to też mutuje wejściowy string
  • zamiast "orowania" iluś wyrażeń zamieniłbym je na osobne, które łatwiej byłoby czytać

W ogólnym przypadku:

  • jak wyrażenie rośnie to bardzo szybko może stać się nieczytelne
  • im dłuższe zapytanie tym większa szansa, na to, że będzie nieoptymalne (jeśli używany silnik używa NFA i powrotów, przy DFA nie ma takich problemów)
  • najczęściej używane PCRE nie jest opisem języków regularnych (bo backreferencje)
13

W wyrażeniach regularnych wkurza mnie wszystko i wolę ich nie stosować.

Masz problem? Chcesz go rozwiązać za pomocą wyrażeń regularnych? No to masz już dwa problemy.

3

Walidacja [A-Za-z] a input przychodzi w Unicode :P Tak poza tym to unicode powinien zostać zdelegalizowany.
Widziałem kiedyś nawet przykład XSS oparty na tym, że różne parsery różnie traktują znaki podobne do innych liter typ z,ż,ź

9

Najbardziej wkurza mnie to, że jeśli muszę już z nich skorzystać to dzieje się to na tyle rzadko że zawsze zdążę zapomnieć wszystko czego się nauczyłem i muszę uczyć się od nowa.

2

Brak jakiegoś sensownego, off-linowego edytora do tego ustrojstwa.
Takiego z możliwością dostosowania kolorowania składni i stosowania wieloliniowego zapisu, który ostatecznie zostanie sparsowany do jednego stringa.
Czyli takiego SASS dla wyrażeń regularnych.

No chyba, że coś takiego istnieje, a ja nic nie wiem.

1

Kiedyś musiałem się z tym zmierzyć nieco poważniej i zniechęciła mnie składnia niczym w języku BrainFuck ( https://pl.wikipedia.org/wiki/Brainfuck ).
Nie mówię, że dziś nie korzystam ... ale staram się unikać. Analizowanie nieco większych wyrażeń po kilku latach od napisania bywa bardzo bolesne.
Myślę, że na złość programistom wymyślił to sam diabeł po tym jak wkur.... się na C++.

3
  1. Składnia. Kiedyś ogarniałem jakieś podstawy tego jak regex działa, dziś już nie pamiętam nic. Łatwiej byłoby mi tego używać gdyby to było jakoś sensownie zaimplementowane w język zamiast kilku krzaków z nawiasami. Mniejsza szansa na pomyłkę, łatwiej to czytać (i robić CR) osobie która nie musiała tego ustrojstwa nigdy dotykać.
  2. Metoda copy-paste'a nie zadziała, bo i tak każdy język implementuje to po swojemu, więc ciężko nawet stawiać pierwsze kroki na przykładach z neta.
1

Raz musiałem powyciągać coś z faktur w pdfach i szlag mnie trafiał jak to jest skonstruowane. Jeden monitor to był jakiś edytor online, drugi kod a trzeci wynik ;-) rzadko kiedy udało mi się to dobrze napisać bo wychodziły jakieś nie ścisłości.

2

Najbardziej wkurzaja mnie wyrazenia regularne

3

Jeśli rozwiązujesz jakiś problem za pomocą wyrażeń regularnych, to masz dwa problemy :)

1

I jeszcze wkurza mnie, że wewnątrz przedziałów znaki specjalne tracą swoje znaczenie, więc do tej pory nie wiem, jak zrobić (prawidłowo) coś takiego:

[ ("„^]
z
[ .,)"”$]

Dla czytelności rozbite na 3 wiersze, a miałoby wyłapać każdą pojedynczą literkę "z" otoczoną odstępami, interpunkcją albo znajdującą się (i tu jest problem) na samym początku albo końcu ciągu.

2

Samo korzystanie z regularnych ekspresji ( ;) ) to już rak sam w sobie, szczególnie że zazwyczaj jest używany tam, gdzie proste operacje na stringach dają radę ( EndsWith, StartsWith, Contains ), a tam gdzie faktycznie się przydaje, to szybko powstaję coś, co wygląda paskudnie.

Dziwie się, że nie ma jakiegoś Regexa funkcyjnego, że się składa funkcję zamiast tego dziwnego syntaxu

2

Najbardziej wkurzają mnie użytkownicy. Wielu z nich uważa się za wielkich programistów a płaczą przy pierwszym lepszym wyrażeniu regularnym. Ledwo zobaczą \d+ i biegną do mnie po pomoc.
title
A tak na poważnie: implementacja w różnych językach - w Javie nie ma literału wyrażeń regularnych i trzeba wpisywać je do Stringa. Potem wychodzą takie potworki jak \\d+\\s\\\\[\\\\]. W Perlu taka zabawa jest prosta

print "dupa\n" if /^\w+$/i;

A z drugiej strony to wina implementacji a nie wyrażeń.

1
Freja Draco napisał(a):

I jeszcze wkurza mnie, że wewnątrz przedziałów znaki specjalne tracą swoje znaczenie, więc do tej pory nie wiem, jak zrobić > wyłapać każdą pojedynczą literkę "z" otoczoną odstępami, interpunkcją albo znajdującą się (i tu jest problem) na samym początku albo końcu ciągu.

No i przez was wymyśliłam :p

(^|[\s\(\"„«»])(z)([\s\)\"”«»,.?!:;]|$)
(^|[\s\(\"„«»])
(z)
([\s\)\"”«»,.?!:;]|$)
1
Freja Draco napisał(a):
Freja Draco napisał(a):

I jeszcze wkurza mnie, że wewnątrz przedziałów znaki specjalne tracą swoje znaczenie, więc do tej pory nie wiem, jak zrobić > wyłapać każdą pojedynczą literkę "z" otoczoną odstępami, interpunkcją albo znajdującą się (i tu jest problem) na samym początku albo końcu ciągu.

No i przez was wymyśliłam :p

(^|[\s\(\"„«»])(z)([\s\)\"”«»,.?!:;]|$)
(^|[\s\(\"„«»])
(z)
([\s\)\"”«»,.?!:;]|$)

BrainFuck i tyle! Zapytam Cię za kilka miesięcy o to co to wyrażenie robi :-)

3

Mnie najbardziej wkurza, że nie mogę tego na stałe zapamiętać. Dla mnie po prostu to nie jest intuicyjne. Szczególnie jak trzeba coś zrobić w innym języku niż polski/angielski.
No i jak wiele osób tutaj nigdy po 3 miesiącach lub może szybciej nie pamiętam co jakieś bardziej skomplikowane wyrażenie robiło.

1

Większość tego co już wspomniano, oraz to że nie mogę spamiętać które znaki są łykane dosłownie a które są jakimś elementem składni i trzeba je escape'ować.
Zwłaszcza też że to zależy od implementacji.

Oraz poważne ograniczenia składni która jest nastawiona na pozytywne dopasowywanie, a ssie w przypadku potrzeby dopasowania negatywnego (znajdź teksty które NIE pasują do wzorca).

W kodzie staram się nigdy nie stosować. Może się zdarzyło raz czy dwa…
Regexpów używam głównie do bardziej złożonych operacji zamiany tekstu w edytorze.

5

W mojej pierwszej pracy był taki jeden Piotrek, który pisał magisterkę z wyrażeń regularnych, i on faktycznie je w pełni umiał, potrafił parsować w locie i napisać dowolne z głowy. I w tej pracy, każdy kto chciał napisać wyrażenie regularne po prostu szedł do Piotrka i mówił, co potrzeba.

Tak więc obecnie najbardziej w wyrażeniach regularnych wkurza mnie to, że takiego Piotrka nie ma w każdej pracy. :D

2

Tego że są nieczytelne przez to że zazwyczaj piszą je ludzie którzy ich nie znają nawet na podstawowym poziomie, lub którzy chcieli na siłę ich użyć w miejscu gdzie zwykły kod byłby dużo bardziej czytelny.

Potem są w kodzie wyrażenia typu:

((a|b){1,1})

zamiast

[ab]

Przydałoby się żeby IDE lub kompilator podpowiadał o zbędnych nawiasach jeśli nie są wykorzystane przypasowania, o nawiasach okrągłych użytych zamiast kwadratowych, o tym że kwantyfikator {,} można zastąpić ? / + lub *, że znaki nie muszą być escapeowane w [] itp. Nie mówię już o przypadkach gdzie jest niepotrzebnie użyte lookbehing czy lookahead bo takie rozwiązanie ktoś znalazł na stackoverflow a w danym przypadku jest zbędne, bo tego bez zaawansowanej sztucznej inteligencji się nie wychwyci.
Nie we wszystkich implementacjach można też wyrażenie rozbić na linie i komentować wewnątrz wyrażenia, a czasem jest to przydatne.

Ale ogólnie już się przyzwyczaiłem za każdym razem gdy trafiam na wyrażenie regularne w kodzie to zawiera ono błędy (zazwyczaj przepuszcza zbyt dużo, przez widoczny błąd), lub jest przekombinowane - często nawet do 1/3 znaków z wyrażenia wylatuje

8

Osobiście uważam, że złożone regexy warto prostu dokumentować. Na przykład:

# clear links "[text](url)" -> "text"
value = re.sub(
    (
        '\['     # starting [
        '(.*?)'  # text
        '\]'     # closing ]
        '\('     # starting (
        '.*?'    # url
        '\)'     # closing )
    ),
    '\g<1>',     # replace with first captured group
    value,
)

Cokolwiek czytelniejsze od

value = re.sub('\[(.*?)\]\(.*?\)', '\g<1>', value)

Zgodnie z filozofią "programy powinno się pisać jakby były regularnie czytane przez człowieka i czasami wykonywane przez komputer". Tak, zgadza się, generalnie według tzw. "dobrych praktyk" nie należy komentować "oczywistych" instrukcji i coś takiego

i = i + 2 # add 2

jest raczej ewidentnie złe. Mam jednak wrażenie, że zasada ta nie do końca powinna obowiązywać w przypadku regexów, bo zbyt często mają one postać nieczytelnej zbitki symboli.

0

To, że regexa nie da się odróżnić od kodu w Perlu i nigdy nie wiem co jest co

4

To zabrzmi jak reklama, ale odkąd odkryłem onlinowy edytor wyrażeń regularnych (https://regex101.com/), praca z nimi stała się całkiem znośna.

I jedyne co mi teraz podnosi ciśnienie to zwykle obsługa białych znaków, końców nowej linii, sterowania zachłannością poszczególnych operatorów.

3
neves napisał(a):

To zabrzmi jak reklama, ale odkąd odkryłem onlinowy edytor wyrażeń regularnych (https://regex101.com/), praca z nimi stała się całkiem znośna.

Programiści Perla go nienawidzą! Odkrył sposób na proste tworzeni wyrażeń regularnych

1 użytkowników online, w tym zalogowanych: 0, gości: 1