Perl будет хорошим инструментом для этого (если вы настаиваете на использовании Regex), так как он поддерживает изменение регистра в шаблонах подстановки:
\l => изменить первый символ (следующей переменной соответствия) на нижний регистр \L => изменить все символы (следующей переменной соответствия) на нижний регистр \u => изменить одиночный символ (из следующей переменной соответствия) в верхний регистр \U => изменить все символы (из следующей переменной соответствия) в верхний регистр
Если все, что вам нужно, это преобразовать (просто / тривиально!) Переменные и имена методов а-ля thisForExample в this_for_example.
Для этого достаточно одного регулярного выражения:
echo 'thisForExample = orThisForExample();' \
| perl -pe 's/(?<=[^A-Z])([A-Z]+)(?=[^A-Z])/_\L\1/g;'
//output: "this_for_example = or_this_for_example();"
Как только вы ожидаете встретить (довольно распространенные) имена, такие как ...
fooURL = URLString + URL + someURLFunction();
... у тебя проблемы. Глубокая проблема .
Посмотрим, что с этим делает наше выражение:
echo 'fooURL = URLString + URL + someURLFunction();' \
| perl -pe 's/(?<=[^A-Z])([A-Z]+)(?=[^A-Z])/_\L\1/g;'
//output: "foo_url = _urlstring + _url + some_urlfunction();"
Довольно плохо, а?
И еще хуже:
синтаксически невозможно различить между (довольно распространенным) именем переменной"URLString" и именем класса"NSString".
Заключение : Регулярное выражение само по себе довольно взлома и подвержено ошибкам для такого рода задач. И просто недостаточно . И вы не хотите, чтобы один вызов оболочки мог потенциально испортить всю вашу кодовую базу , не так ли?
Существует причина, по которой в XCode есть инструмент рефакторинга , который использует грамматическое дерево clang, чтобы различать синтаксически идентичные (по шаблону как минимум) имена переменных и классов.
Это проблема для контекстно-свободных языков , а не обычных языков . Следовательно, регулярные выражения не могут справиться с этим . Вам понадобится грамматика без контекста для создания языкового дерева и т. Д. (И в то время вы только начали создавать компилятор )
Также: зачем использовать under_scores в любом случае? Если вы используете XCode, то вы, вероятно, в любом случае пишете код в ObjC (++) или аналогичном, где здравый смысл использовать camelCase. Я и, вероятно, в значительной степени все иначе возненавидят вас за то, что вы однажды заключили с нами ваш подчеркнутый код ObjC / C /….
Альтернативный ответ:
В комментарии к Paul R вы сказали, что в основном объединяете два проекта, один с именами с заниженной оценкой, другой с именами в формате camelCase .
Тогда я бы посоветовал вам переключить вашу базу кода under_scored на camelCase . По двум причинам:
Превращение имен under_scored в camelCased гораздо менее подвержено ошибкам, чем наоборот. (То есть: конечно, только в среде, где доминирует camelCase! Было бы так же подвержено ошибкам, если бы вы в основном имели дело с кодом under_scored в XCode. Думайте об этом как о «просто меньшем количестве кода, который потенциально может сломаться»;)) 1101 *
Цитирую свой ответ:
[…] Я и, вероятно, в значительной степени
все иначе будут вас ненавидеть за то, что вы однажды заключили сделку с вашим
Код ObjC / C /… подчеркнут. [...]
Вот простое регулярное выражение для преобразования under_score в camelCase:
echo 'this_for_example = _leading_under_score + or_this_for_example();' \
| perl -pe 's/(?<=[\w])_([\w])/\u\1/g;'
//output: "thisForExample = _leadingUnderScore + orThisForExample();"