Регулярні вирази є потужним інструментом в арсеналі програміста, але - бувають випадки, коли вони не є найкращим вибором або навіть відверто шкідливі.

Простий приклад №1 - це розбір HTML за допомогою regexp - відомої дороги до численних помилок. Напевно, це також пов’язано з розбором загалом.

Але, чи існують інші чітко невисокі області для регулярних виразів?

ps: " Питання, яке ви задаєте, видається суб'єктивним і, ймовірно, буде закритим. " - таким чином, я хочу підкреслити, що мене цікавлять приклади, коли використання регулярних виразів, як відомо, викликає проблеми.

Не використовуйте регулярні вирази:

• Коли є парсери.

Це не обмежується HTML . Простий дійсний XML не може бути розумно розібраний з регулярним виразом, навіть якщо ви знаєте схему і знаєте, що вона ніколи не зміниться.

Не намагайтеся, наприклад, проаналізувати вихідний код C # . Розбирайте її замість цього, щоб отримати змістовну структуру дерева чи жетони.

• Більш загально, коли у вас є кращі інструменти для виконання своєї роботи.

Що робити, якщо потрібно шукати лист, малий і великий? Якщо ви любите регулярні вирази, ви їх будете використовувати. Але хіба не легше / швидше / читабельніше скористатися двома пошуками один за одним? Швидше за все, на більшості мов ви досягнете кращої продуктивності та зробите свій код читабельнішим.

Наприклад, зразок коду у відповіді Інго є хорошим прикладом, коли ви не повинні використовувати регулярні вирази. Просто шукайте foo, а потім bar.

• При розборі людської писемності.

Хороший приклад - фільтр непристойності. Загалом це не тільки погана ідея , але й ви можете спокуситись, використовуючи регулярні вирази, і ви зробите це неправильно. Існує безліч способів, як людина може написати слово, цифру, речення і зрозуміє інша людина, але не ваш регулярний вираз. Тож замість того, щоб зловити справжню непристойність, ваш регулярний вираз витратить її час, завдаючи шкоди іншим користувачам.

• Під час перевірки деяких типів даних.

Наприклад, не перевіряйте електронну адресу за допомогою регулярного виразу. У більшості випадків ви зробите це неправильно. У рідкісному випадку ви зробите це правильно і закінчите 6-ти символами 343 символів, що кодують жах .

• Коли у вас немає правильних інструментів чи не піклується про чистий код.

Без правильних інструментів ви будете робити помилки. І ви їх помітите в останній момент, а може, і ніколи. Якщо вам не байдуже чистий код, ви напишете рядок із двадцяти рядків без коментарів, пробілів і нових рядків.

• Коли ваш код буде прочитаний. А потім читайте знову, і знову і знову, кожен раз різними розробниками.

Якщо серйозно, якщо я беру ваш код і мушу його переглянути чи змінити, я не хочу витрачати тиждень, намагаючись зрозуміти двадцять рядків з великою кількістю символів.

Найголовніше: коли мова, яку ви розбираєте, не є звичайною мовою .

HTML це НЕ звичайну мову і розбір його формальному виразу є НЕ можливо (не тільки важко або дорога до баггі коду).

На stackoverflow часто можна побачити, як люди запитують регулярні вирази, які з'ясовують, чи не містить певний рядок те чи інше . Це, ІМХО, перевертаючи мету регулярного вираження. Навіть якщо існує рішення (використовуючи негативний погляд за твердженнями або подібними матеріалами), часто набагато краще використовувати регулярний вираз для того, для чого він був створений, і обробляти негативний випадок програмною логікою.

Приклад:

# bad
if (/complicated regex that assures the string does NOT conatin foo|bar/) {
    # do something
}

# appropriate
if (/foo|bar/) {
    # error handling
} else {
    # do something
}

Два випадки:

Коли є простіший шлях

• Більшість мов надають просту функцію, як INSTR, щоб визначити, чи є одна рядок підмножиною іншої. Якщо це те, що ви хочете зробити, використовуйте більш просту функцію. Не пишіть власний регулярний вираз.

• Якщо є бібліотека для виконання складної маніпуляції з рядком, використовуйте її, а не записуйте власний регулярний вираз.

Коли регулярні вирази недостатньо потужні

• Якщо вам потрібен аналізатор, використовуйте аналізатор.

Регулярні вирази не можуть ідентифікувати рекурсивні структури . Це основне обмеження.

Візьміть JSON - це досить простий формат, але оскільки об’єкт може містити інші об'єкти як значення членів (довільно глибокі), синтаксис є рекурсивним і не може бути розбитий регулярним виразом. З іншого боку, CSV може бути проаналізований регулярними виразами, оскільки він не містить рекурсивних структур.

Коротше кажучи, регулярні вирази не дозволяють шаблону посилатися на себе. Ви не можете сказати: у цей момент синтаксис знову відповідає всій схемі. Інакше кажучи, регулярні вирази відповідають лише лінійно, він не містить стека, який би дозволив відстежувати, наскільки глибоко це вкладений шаблон.

Зауважте, це не має нічого спільного з тим, наскільки складним чи перекрученим є формат. S-вирази дійсно дуже прості, але їх неможливо розібрати за допомогою регулярного вираження. CSS2, з іншого боку, є досить складною мовою, але не містить рекурсивних структур і для цього може бути розібраний з регулярним виразом. (Хоча це не вірно для CSS3 через вирази CSS, які мають рекурсивний синтаксис.)

Так це не тому, що це некрасиво або складно або схильно до помилок аналізувати HTML, використовуючи лише регулярний вираз. Це так, що це просто неможливо .

Якщо вам потрібно проаналізувати формат, який містить рекурсивні структури, вам потрібно хоча б доповнити використання регулярних виразів стеком, щоб відстежувати рівень рекурсивних структур. Як правило, це працює аналізатор. Регулярні вирази використовуються для розпізнавання "лінійних" частин, а спеціальний код за межами регулярного вираження використовується для відстеження вкладених структур.

Зазвичай такий аналіз розбивається на окремі фази. Токенізація - це перша фаза, де регулярні вирази використовуються для поділу введення на послідовність "лексем", таких як слова, пунктуація, дужки тощо. Розбір - наступна фаза, де ці лексеми розбираються в ієрархічну структуру, синтаксичне дерево.

Отож, коли ви чуєте, що HTML або C # не можна розбирати за допомогою регулярних виразів, пам’ятайте, що регулярні вирази все ще є важливою частиною аналізаторів. Ви просто не можете розбирати таку мову, використовуючи лише регулярні вирази та без допоміжного коду.