У моей студии большая кодовая база, которая разрабатывалась более 10 лет. Стандарты кодирования, с которых мы начали, были разработаны небольшим количеством разработчиков, и задолго до того, как нам пришлось беспокоиться о каких-либо стандартах, связанных с C++.
Недавно мы начали собственный небольшой научно-исследовательский проект и обновили наши соглашения о кодировании, чтобы они больше подходили для нашей среды. Исследования и разработки будут интегрированы в существующий код проекта. Одна из основных проблем, с которыми мы сталкиваемся, заключается в том, что теперь у нас есть два стандарта для двух областей работы, и теперь кодовые базы пересекаются. Мне не нужны два стандарта в студии, и я на самом деле вполне счастлив двигаться вперед с единым стандартом. («Как» того, как мы попали в эту ситуацию, не важно - просто то, что мы есть, и я надеялся, что это не так.)
Проблема заключается в рефакторинге существующего кода. Я не очень хочу, чтобы две кодовые базы (одна относительно маленькая и одна очень большая) выглядели по-разному. Мне интересно провести некоторый рефакторинг одной из существующих кодовых баз, чтобы она соответствовала другому стандарту. Проблема в том, что меньшая кодовая база (IMO) является более желательным стандартом.
Я начал искать инструмент, который мог бы сделать за меня крупномасштабный рефакторинг. Меня не интересует перестановка и ужесточение кода. Я заинтересован в изменении таких вещей, как
class my_class {}
....
class my_class A;
к
class MyClass {}
....
class MyClass A;
В основном переименование функций / переменных. Я бы предпочел не использовать что-то вроде Visual Assist, потому что это займет много времени. У меня более 10000 исходных файлов / файлов заголовков с сотнями тысяч строк кода. Использование VA по одному классу за раз будет убивать время и не стоит затраченных усилий.
Я наткнулся на Вера в другом посте на SO. Похоже, что он может работать и делать это хорошо. Я хотел бы знать, есть ли у кого-нибудь конкретный опыт использования Vera в той ситуации, в которой я нахожусь, или какие-либо другие рекомендации по инструментам, которые могут выполнить эту работу. Я думаю, что важно, чтобы этот инструмент действительно понимал структуру кода, чтобы мы не заканчивали просто переименованием переменных в режиме поиска / замены, потому что это приведет к незаметным ошибкам, если не будет сделано осторожно.
Обновлено: В то время как мой пример показывает, что я собираюсь использовать _ между именами к обозначению типа Camelcase, для нас может быть более выгодным перейти в другую сторону. Я действительно ищу универсальное решение, которое поможет при крупномасштабном переименовании.
Спасибо.





Я думаю, что переименование переменных будет непростым делом - к счастью, вы переходите от соглашения _ к Capitalized, поэтому это будет не так сложно (хотя _ легче читать и лучше)
Я бы взял средство для украшения кода (например, Художественный стиль или Uncrustify) и изменил бы их, чтобы выполнить преобразование. Для этого преобразования вам понадобится всего несколько пользовательских правил, так что это не будет слишком сложно.
крики, значит, у тебя впереди большая работа. Я бы сделал это по частям - когда вы меняете модуль, меняйте имена. Вы также увидите, какие из них остались нетронутыми. Ваша команда тоже должна быть согласна с практичностью такого подхода.
PS _ - это примерно стандарт, используемый в коде C++, Страуструп считает, что они обеспечивают лучшую читаемость, а библиотеки STL и boost используют их, так что это имеет смысл.
Мой процесс состоял в том, чтобы переименовывать каждый раз, когда кто-то касается данного модуля. В конце концов, все модули будут переработаны, но инкрементный подход приведет к меньшему нарушению кода (при условии, что у вас есть полный набор тестов .;))
возвращаясь к старому старому вопросу, но именно так мы провели большую часть нашего рефакторинга.
Я внес такие изменения, используя собственные скрипты. Если могу, использую sed. В противном случае я буду использовать язык сценариев с хорошей поддержкой регулярных выражений. Это грубый хакер, который обязательно приведет к ошибкам, но если вы не найдете лучшего решения, это путь вперед.
Я согласен, если инструменты слишком медленные для вас, а преобразования просты - как в приведенном выше примере - небольшой скрипт будет работать как шарм, особенно если у вас есть автоматические тесты, которые проверяют, все ли по-прежнему работает
ИМХО, переименование переменных просто не стоит усилий. Важно, чтобы код был надежным, читаемым и производительным. Просто примите тот стиль, который использовался раньше, и потратьте свое время на важные дела.
Переименование переменных станет проблемой, если код с новым стилем вызывает функции или использует классы из кода старого стиля. Хотя я согласен, что это не так важно, как надежность, через некоторое время становится трудно писать.
Дело не только в переменных. Речь идет о последовательности, что, на мой взгляд, важно. Поверьте, я не мог понять, действительно ли это важно, но я думаю, что некоторая степень согласованности в кодовой базе стоит определенных усилий.
Иногда это того стоит. Если вы используете венгерскую нотацию, тип переменной может быть закодирован в имени. Измените тип переменной, и вам может потребоваться также изменить имя. Я никогда не использую обозначения в новом коде, но сейчас я в основном работаю со старым кодом, и он есть повсюду.
Если у вас нет (1) достаточно полного набора надежных и автоматизированных тестов и (2) инструмента рефакторинга, который понимает семантику C++ (я не слышал о таких инструментах), я бы посоветовал не делать автоматических переименований. Везде, где я работал, практика всегда заключалась в рефакторинге только тех модулей, над которыми вы работали в данный момент. Это длительный, но относительно безболезненный процесс.
Возможно, вы захотите рассмотреть возможность изучения «свинина», который используется, создается и поддерживается людьми из Mozilla, для выполнения в значительной степени автоматизированного анализа исходного кода C++, включая преобразования исходного кода, такие как рефакторинги. Он поддерживает сценарии с использованием JavaScript и поддерживает довольно сложный семантический анализ и преобразования. Так что переименование символов - одна из самых простых вещей для свинины.
Теперь, когда Плагины GCC уже в разработке, вполне вероятно, что в будущем такие вещи станут проще.
Мой пример, возможно, был предпочтением, но далек от уверенности. Мы можем пойти другим путем. Мне больше любопытно, как выполнить эту работу. Я отредактировал вопрос для ясности.