Если используется notepad++, то для него есть плагин, работает, кажется, на базе AStyle, скачивается и устанавливается из самого редактора.

Хм, я стилизую каждые пару строчек, почти в непрерывном режиме.
Непривычный стиль сбивает внимание.
Рефакторинг опять же требует повторной стилизации.
Здесь как раз стилизация облегчает сравнение версий.

А вот стилизация сторонних исходников, особенно в больших проектах затрудняет сравнение версий.
Хотя бы тупо потому что скажем все файлы будут фиксироваться как содержащие изменения после стилизации, а файлов может быть сотни. В одной GUI их больше 500.
И вот такому горе стилизатору придется в случае проблем проверять вручную сотни файлов.
А если оставить их в покое, то реальные отличия версий находятся на порядок быстрее.

Попробовал polystyle, все получается. Спасибо!

Ещё забыли достаточно мощную шутку Understand for C++. Есть в закромах /pub/UTILITIES/IDE_Editors/.

Аналогично.

Это будет зависить от того, как строите свою работу.

Повторяю:
1) Прогнать можно и вновь пришедшие, можно хранить экземпляр до стилизации.
2) В ручную сравнивать совершенно незачем, ибо есть мощные, умные, понимающие язык сравнилки подддерживающие пакетную обработку. Буквально секундное дело и сравнить и синхронизировать и подредактировать все средствами сравнилки.

Что-то не понял.
Ситуация:
стилизовали пару сотен файлов. Сравниватель файлов покажет что они по датам разные и по содержимому.
Тогда вынуждены для каждой пары файлов открывать сравниватель и убедится что они просто отличаются стилем.

Хотите сказать, что есть сравниватели которые гарантированно после любого стилизатора могут сказать что сорсы абсолютно одинаковые и юзеру даже не надо их открывать?
Что-то сомневаюсь, эти сравниватели должны очень хорошо тогда парсить C-и на уровне проекта и быть очень медленными.

1)И в ТРНТИЙ раз - при прогоне обеих исходников через стилизатор даже самый тупой сравнитель сможет их сравнить на соответствие.

2) Да, хорошие, в том числе и тот, который называл, парсят на уровне не только Си, но и других языков и НЕ МЕДЛЕННЫЕ никак не медленнее компилятора. Поддерживают сравнение и содержимого директорй. Сравнивают не только исходники, но и PDF (а чего новенького в новой редакции документа появилось).

Ну, реальная жизнь вашими use-case не ограничивается.. Я, например, на работе пишу в стиле, к которому привык. А перед коммитом в общий репозитарий все приходится приводить к принятым в команде coding style.

Ха! на самом деле, жизнь бывает еще интереснее - на одной из моих предыдущих работ к власти дорвались какие-то старперы-выходцы из Sun. Эти идиоты всю свою жизнь (и по сей день) писали на чистом Ц (даже не Ц99), руководствуясь замечательным документом типа "Sun co. coding style guidelines" oт 1998 (!) года. Мало того, что они ограничивали длинну строки 80 символами, так эти гайды изобрели вообще крышесносящую систему отступов в виде смеси пробелов и табов! Из приличных людей никто точно не знал где следует использовать табы, а где пробелы.. По этому поводу загорались жаркие дискуссии с апелляциями к главным бородатым-пузатым красноглазикам- экспертам. Я пытался настроить системы форматирования исходников под их [...]нутые стандарты, но так ничего и не вышло
Короче, теперь на всех собеседованиях на работу я спрашиваю у потенциальных работодателей про их coding standards. Если они при этом гордо надуваются и начинают рассказывать, как круто они используют максимум 80 символов в строке(при этом причины они объяснть не могут) , форматирование в стиле KR и любое отступление от подобных правил карается выговором, то они идут лесом, с дураками лучше не связываться

Похоже вы не поняли проблемы.
Я скачал вашу программу по ссылке. Хоть вы и даете почему-то ссылки только на коммерческие сомнительные продукты.
Она делает не намного больше чем умеет Total Commander.
Стилизованные файлы отмечает как отличающиеся. Т.е. по сути ничем в описанной мной ситуации не помогает.
Приходится вручную! , не силой мысли, не телепатически, а тупо щелкая сотни раз мышью открывать все файлы и проверять их содержимое.



Почему же, именно мой use-case вы и привели в пример.
Пишете как попало, а потом приводите к единому стилю.
И для того это делается чтобы потом было проще сравнивать.

Вон в Python отступы вообще являются элементами синтаксиса и все его любят.

Коммерческие - да. Полагаю, что стабильность и развитие продукта много важнее его бесплатности. На счет "сомнительности" - ну не порите чушь. Я пользують несколько десятилетий добротными, развиваемыми и поддерживаемыми продуктими. Это уже много стоит.

Да ну

Стадо слонов-то и не приметили. Там РАЗНЫЕ уровни отличия и разные механизмы сравнения. Отличие, например, в форматировании, комментариях... отмечаются, как несущественные.
Хотите - можете игнорировать, можете сразу синхронизировать.

Ну если в голове только микроскопом гвозди забивать, то тогда да . А по нормальному сравнение всего дерева директорий, оценка по отметке и расцветке имени файла уровня различий, рассматривание
только тех, кто имеет существенные с точки зрения заданного языка различия (текст и навигация по нему тоже размечена в зависимоти от существенности ). В процессе рассатривания синхронизация различий, как индивидуально, так и скопом.

Я приводил этот пример еще ДО ВАС, как вариант тупого лобового решения. Вополне работает. Претензий нет. Только можно и удобннее. Не гоаоря уже о том, что всякое правило НУЖДАЕТСЯ в исключениях. Я, например, привык места временных решений, или подлежащие дополнительному анализу размещать с нарушением общестильных отступов - достаточно хорошо заметны, но прогонять их через форматтер для последующего "упрощения" сравнения не хорошо будет.

Вот ссылка из мануала вашей программы


Как видно программа может сказать только то что файлы отличаются.
Никакого парсинга c-и файлов не делает и отличить существенные и несущественные изменения не может.
Щелкаю Ignore Unimportant Differences и ничего не происходит, прога не считает пробелы неважным отличием.

Ха! Я в таком случае использую спец. маркер - тройной слеш /// (для си, для асм - ;;;)
Для меня он означает "Обрати внимание! Здесь есть временная вставка!"
Если вставка однострочная - в конце строки, для многострочной отделяю пустыми строками блок от остального текста и в начале этого блока ставлю ///
За годы уже натренировался зрительно выделять /// из массы кода

Спасибо. У меня есть сама программа и я с ней работаю лет двадцать с гаком. И менно ТАК, КАК ОПИСАЛ c ПАРСИНГОМ Cи не только Си файлов. Так-что обсуждать Ваши явные непонимания того, как с ней работать в режиме Rules-based comparsion, как использовать готовые правила под языки и создавать свои, я просто не буду.


Тоже вариант. Только если в чужих исходниках так отмечать, то мешаются любители использовать разделители ////////////////////////////////////////////////////////////////////////////////


Отступы удобны тем, что у меня в редакторе они меняются для любого существующего блока отступов на хоткее. Очень быстро менять.
более существенные перманентые пометки отмечаются тоже на хоткее таким:
//zlt[
.....
//]zlt
Надо будет и снятие такой пометки сделать на автомате, но лет 20 забываю это написать

Если будете использовать Doxygen, то такой способ не годится. Такие строки используются для документирования.
Я задумал ставить //?

я перешел на условную компиляцию с внятно написанными условиями, чтобы не нужно было просматривать десятки файлов в поисках временных вставок

#ifdef UART0_USED_FOR_RS485
....
#endif

Все условия собираются в одном файле.
Тупиковые условия постепенно исключаются, чтобы не загромождали код.