Как определить «переломный момент», особенно при программировании регулярных выражений?

Question

G'day,

Редактировать: Хотя этот вопрос часто затрагивает ситуацию, которая может возникнуть в программировании, я всегда замечал, что есть смысл при работе с регулярными выражениями, особенно. в Perl и в shell-программировании, где пытаются отловить последние несколько крайних случаев:

• требуется гораздо больше времени для расширения вашего регулярного выражения, что может означать
• чрезмерная сложность в регулярном выражении, которая приводит к
• будущие проблемы с обслуживанием из-за сложной природы регулярных выражений, особенно там, где это не в Perl, так что нет опции nice / x, позволяющей легко документировать фрагменты регулярных выражений.

Я отвечал на этот вопрос " Существует ли довольно простой способ для сценария сказать (из контекста), является ли" она "притяжательным местоимением? ", и часть моего ответа состояла в том, что вы добираетесь до точка, в которой погоня за последними несколькими процентами пограничных случаев не требует дополнительных усилий и времени для расширения вашего регулярного выражения, сценария оболочки и т. д. Становится проще просто пометить пограничные случаи и выполнить их вручную.

Меня удивило, есть ли у людей простой способ понять, что они достигли такого переломного момента? Или это что-то, что приходит только с опытом?

Кстати, хотя этот другой вопрос также касается "переломных моментов" , он касается того, когда решено начать автоматизировать манипуляции с файлами, а не когда "достаточно достаточно".

Answer 1

Всякий раз, когда я чувствую, что моя задача по созданию регулярных выражений или сценариев оболочки занимает примерно столько же времени, сколько я трачу на ручную работу, я знаю, что достиг «переломного момента».

Тогда, если это быстрый и грязный инструмент для более масштабной задачи, я продолжу, как вы описываете: большая часть работы с regex / script и крайними случаями помечается и обрабатывается вручную.

Если это то, что может быть использовано повторно (например, в автоматических регрессионных тестах), я трачу время на совершенствование своего инструмента (разбиение задач или переключение на perl) и / или на то, чтобы входные данные соответствовали некоторым предположениям.

Answer 2

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

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

Проблема в том, что регулярное выражение используется для решения проблемы другого типа. Интенсивное использование осмотров часто свидетельствует об этом. Если проще следовать последовательности обычного кода, который решает ту же проблему простым способом, то это правильное решение, независимо от того, насколько коротким будет регулярное выражение.