Clang-Tidy для автоматического рефакторинга кода

[tangro]

Так себе идея автоматически править код. Ладно там ещё генирировать с нуля — в этом есть смысл (никто генерированный код никогда читать и править не будет, пока он работает). Но тут роботы встряют в середину разработки. Сначала человек написал код, потом скрипт его изменил, потом снова пришел человек править баг — и вдруг оказывается, что нет никого, кто понимает почему текущий код написан так, как написан. Появился ли баг из-за работы робота или был и раньше?

Ну и во-вторых, проблема переменной «num» не в том, что она с маленькой буквы и в ней нет префикса. Проблема в том, что переменной «num» в коде попросту быть не должно. Должна быть переменная «number», а ещё лучше «numberOfElements» или что там она считает. И вот такой рефакторинг вам clang-tidy не сделает.

[zloddey]

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

Так ведь этот вопрос обычно через системы контроля версий решается. Каждое изменение, что от человека, что от робота, оформляется в отдельный коммит. Когда хотим найти источник или автора проблемы — смотрим историю. Если всё ещё неясно — делаем bisect. Достаточно тривиальный кейс при правильном подходе к сохранению истории изменений

[DenisMTyurin]

С этим трудно поспорить — будь у меня выбор, я бы всегда работал только с идеальными проектами, написанными образцовыми разработчиками. К сожалению, реальность такова, что встречаются проекты, которые росли как трущобы — годами и слоями. Смотришь на такой — а там лежат два файла рядом, один от 1996 года, другой от 2020го… Переписать такой проект с нуля — нереально. Посадить человека, который приведет все к одному стилю, — может быть, можно, но такая инвестиция врядли окупится.

Автоматический улучшайзинг кода — это дешевый и немного сердитый способ навести хоть какой-то порядок в таких проектах.

А что касается более умного переименования переменных, то, на мой взгляд, все зависит только от того, сколько времени на это потратить. Нет никакой технической проблемы в том, чтобы обнаружить, скажем, локальную переменную с длинной имени в 1 символ (например i), по типу данных и характеру её использования понять, что используется она как счётчик, и переименовать, скажем, в counter.
Поэтому переименовать с помощью Clang-Tidy переменные num в numberOfElements, там, где это нужно, — тоже не должно быть проблемой.

[X-Ray_3D]

Например, у меня в проекте обновилась внешняя библиотека, у которой поменялось API и типы. Вручную я пробовал править и быстро забил, так как она использовалась повсеместно в тысячах мест. Остался пока на старой версии. Но после прочтения статьи всё-таки решил попробовать мигрировать.

[NN1]

Как раз интересуюсь clang-tidy.
Случайно не используется совместно в работе с Visual Studio?

[DenisMTyurin]

Я сам напрямую из Visual Studio clang-tidy не запускал, но такая возможность точно есть.
Вот здесь пишут что начиная с VS 2019 эта интеграция должна работать «из коробки»: docs.microsoft.com/ru-ru/cpp/code-quality/clang-tidy?view=msvc-160

[aabzel]

А что clang tidy всегда должен работать в тандеме с python ?

[DenisMTyurin]

Python используется вокруг clang-tidy для рутинной автоматизации. То есть для создания заготовок, для пакетного выполнения проверок и т.д. Какой-то особой необходимости в python кроме как для этого нет. То есть clang-tidy.exe собранный - самодостаточен. Его можно просто запускать из командной строки для каждого отдельного объекта сборки. Это будет трудоемко, но если вдруг по какой-то причине python использовать невозможно - то это не блокер.