Pull to refresh

Comments 6

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

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

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

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

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

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

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

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

Sign up to leave a comment.