Comments 28
В проекте LLVM есть инструменты для source-to-source преобразований. Выглядит как очень подходяще для того, чтобы не только выявить нарушения соответствия порядка объявление-определение, но и сразу перестроить на нужный порядок.
Вы @cls0 можете привести скрипт, который решает вот эту конкретную задачу средствами LLVM?
а что указано в правилах если h файл общий для нескольких модулей?
Любопытно было бы узнать, откуда в организациях появляются такие правила оформления исходников...
Любопытно было бы узнать, откуда в организациях появляются такие правила оформления исходников...
Очевидно кто-то очень сильно заинтересован, чтобы высоко технологические проекты в России, скажем так, не слишком быстро доходили до серийного производства.
Любопытно было бы узнать, откуда в организациях появляются такие правила оформления исходников...
Вот как это правило прокомментировал его автор:
Любопытно было бы узнать, откуда в организациях появляются такие правила оформления исходников...
Такое добавили в QtCreator, можете подсмотреть у них в исходниках. Вот связанная задача
Ок, а шапки с комментариями перед функциями он не забудет тоже переместить?
Если имеются ввиду шапки в .h, то они перемещены не будут, т.к. определения приводятся к порядку объявлений, а не наоборот
Если у вас в .cpp есть шапки с комментами, не знаю, такие сценарии видел крайне редко
Я обычно дублирую коментарии в сишниках и ашниках. Потому, что программист, который хочет ознакомиться с API, будет последовательно читать ашник, а программист, который идет по коду, пойдет в основном по сишникам.
Вот вам тема для еще одной статьи.
Придумываем правило: комментарий документации в .h не должен иметь расхождений с дубликатом в .cpp.
Пишем утилиту по автоматической синхронизации шапок комментариев
.h -> .cpp (подсказка, как это можно сделать по-взрослому -> clang умеет привязывать doxygen комменты к узлам AST C++)profit
Ещё дублировать приходится потому, что в эклипсе всплывающая подсказка показывает текст функции из сурса. А программист пользуется хидером. Вот и приходится шапку писать и там и там
Если вы программист на Си, то почему бы не написать собственный линтер на Си и не городить десятки make-файлов? Так уж и быть, линтер вызывать из make-файла.
Начинание хорошее, но реализация странная.
Раз существующие инструменты не имеют нужного функционала, почему бы их не доработать? Исходники то ведь открыты.
К тому же парсить C++ код чем-то отличным от компилятора C++ - так себе идея, ибо неизбежно парсинг будет ломаться на каких-то хитрых случаях с макросами.
Отличное замечание. PVS-Studio не устаёт повторять, что нужно учитывать настройки компилятора, флаги компилятор и параметры сборки (какие-нибудь добавляемые макросы).
Так что правильнее уже парсить препроцессированный исходник (после выхлопа препроцессора).
А можно пойти проще: полностью сгенерированные заголовочные файлы. Даже самописный парсер грамматики должен оказаться не слишком сложным. Берётся cpp-файл и парсится сверху вниз. Встретили функцию - сгенерировали для неё объявление с комментарием. Если функия статическая - пропускаем.
Другие разработчики могут продолжать добавлять в h-файл свой код, просто при следующем запуске генератора файл перезатрётся.
Грамматика C++ очень сложная, и очень зависит от контекста. Например, одна и та же строка может обозначать объявление переменной, а может - вызов функции. Не порезолвив символы с учетом контекста и области видимости, этого даже и не поймешь.
Qt-ный moc ведь так и работает, пытается понять C++ и генерирует метаданные. Но он не полностью C++ понимает и в каких-то сложных случаях ошибается. А там его не один человек пишет, и очень давно.
1) Почему бы сразу не написать утилиту сортировки h-файлов под порядок определения c-файлов? Или, как указали в комментариях выше, почему бы не сделать утилиту для генерации h-файлов из c-файлов, с правильным порядком, комментариями, и прочее? Зачем ограничиваться полумерами? И еще, я так понял, упорядоченность "экспортируемых" переменных не контролируется?
2) Что в вашем понимании “топтаться ногами в скрипте"? Это предъявляемое условие информационной безопасности, или же реально бывали случаи, когда программисты в состоянии аффекта ломали свои же инструменты?
Почему бы сразу не написать утилиту сортировки h-файлов под порядок определения c-файлов?
Это сложная задача. Вот попробуйте сами такую сделать...
Или, как указали в комментариях выше, почему бы не сделать утилиту для генерации h-файлов из c-файлов, с правильным порядком, комментариями, и прочее?
Дело в том что в си файле аргументы по требованиям перечислены в столбик. А такое оформление очень сложно парсить кодом.
Это сложная задача. Вот попробуйте сами такую сделать...
Что в вашем понимании “топтаться ногами в скрипте"?
Можно случайно так поставить лишние пробел, что скрипт перестанет работать.
Стилистический Анализатор: Синхронизация порядка объявлений и определений функций