Правильные отступы, один оператор в строке, разделяющие пробелы вокруг операндов, расстановка фигурных скобок, а также другие рекомендации хорошего стиля кодирования программ определенно помогают, но не всегда в спешке соблюдаются.
Но с разрастанием кода, все же появляется желание использовать этот правильный стиль.

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

обычно это уже есть в средах разработки и большинстве расширенных текстовых редакторов. Что вы используете?

Например, eclipse позволяет определить свой собственный стиль форматирования.
Помогает его соблюдать при наборе программы. При необходимости выделенный кусок форматируется сочетанием Ctrl+Shift+F.
Вам так надо?

Artistic Style
http://astyle.sourceforge.net/

Единственная проблема - выбрать этот "хороший стиль". Для себя можно писать как угодно, лишь бы было удобно с этим кодом иметь дело. При работе в команде обычно приходится следовать coding standards.

Вот чего не надо делать в этом деле так это "автоматизировать"
Это усложняет потом сравнение с предыдущими и последующими версиями.

Если надо форматировать уже имеющиеся исходники, то: GNU Indent .

к smalcom и adnega
Сейчас применяю Dev-C++ (версия 4.9.9.2) под WinXP, а там возможности скромные по сравнению с другими, т.е. сама не форматирует. Пока хотел бы конвертор тоже какой-то скромный, где входной файл мой, а выходной уже стильный...

к CrimsonPig
Загрузил Download Artistic Style 2.05.1 for Windows (441.3 kB), получил c:\AStyle\bin\AStyle.exe, но программа не запускается, оказывается она под Линукс, где у меня не большого опыта.... Хотя пишут for Windows...
А стиль мой немного подпорчен опытом программирования МК на С.

к AlexandrY
Автоматизация меня бы устроила... Дайте только программу...

к Canis Dirus
Скачал GNU Indent и еще попробую ее под FreeBSD, но мне удобней бы по WinXP...

Хм, дам совет: надо скачивать версию экзешника под винды Я как-то скачал и все у меня работает и под ХП и под семеркой.

Еще раз проверил, там только под Линукс, а для винды нет, хотя пишут то - for Windows... Поделитесь для винды, если это возможно...

идем сюда: http://sourceforge.net/projects/astyle/files/
ищем ссылку, типа "Download Artistic Style 2.05.1 for Windows (441.3 kB)"
Идем по ней, скачиваем зип. Проверил - работает под семеркой точно.

1. Есть более, чем достойные сравнивалки - http://www.scootersoftware.com
2. Через форматирование прогоняются ОБА исходника и сравнение становится изумительно простым.



Да есть. http://www.polystyle.com/ Стиль можете собирать свой, а не обязательно тот, который кто-то "хорошим" назвал.

Ещё есть uncrustify. Подобный софт по-русски называется стилизатор, по английски beautifier.

Что-то я не пойму в чем вы пишите исходники. В Notepad-е?
Форматирование в любой стиль поддерживают и Eclipse и Visual Studio и SlickEdit и туча других IDE.
Никаких дополнительных приблуд для этого качать не надо.

Самый мощный по количеству фичей стилизатор содержит наверно SlickEdit.
Там есть и макро язык в котором по одному нажатию можно все дерево исходников стилизовать.

абсолютно верно!
я даже под windows ее пользую!

Специализированные "приблуды" существуют по причине того, что делают свое дело лучше, чем IDE в которых все все понемногу делают. Не говоря о том, что их работа не зависит от того в какой IDE сейчас кто-то что-то делает. Посему лично у меня к редактору подключены внешние.

Если используется 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

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

Для больших кусков теряется начало или конец маркированного блока посему сделал так, как писал постом выше. Кстати строчка отмечается //zlt[]


Терпеть немогу
#ifdef
Чуть опечатка и молча вылетают куски исходника.
А так да, для "совсем постоянных" мест, именно через
#if( ..... )

А, понял в чем ваше тайное знание этой программы.
Намекаете на правила и грамматику которые там нужно конфигурировать.
Так вот правила для C-и там не работают если пытаться сравнивать разные стили.

Или покажите какую грамматику написали вы чтобы эта прога уверенно распознавала разные стили как один и тот же текст.

Не можете описать, можете привычно воспользоватся и подключением перед сравненим внешнего конвертора.

Это очень громоздко.
Когда нужно вставить что-то типа "i=0;", и к тому-же если в разных местах исходника вставить с десяток таких строк, то гораздо проще в конце каждой поставить ///
чтобы потом не забыть их удалить.


Чужие стараюсь не править (и не использовать), а если приходится (изредка) заменяю такие строки на что-то другое, типа //------------------

А в курсе что в Eclipse автоматом обрабатываются все комменты типа // FIXME: или //TODO: или xxx и аккуратно выводятся в табличку tasks с содержащимся в коменте текстом и указанием на файл где это находится



Это еще что за приблуда - внешний конвертер?
Как то все предельно заморочено.
Да и Beyond Compare я уже снес.

Для работы с исходниками использую плагин/библиотеку Colorer, там такое выделение называется to-do comment. Ставлю, когда нужно что-то времменое проверить, а затем не забыть убрать/исправить. Настраивается как сам to-do паттерн, так и цветовая схема, паттерн в моём случае — ;!! (AVR8 asm). Список поддерживаемых языков программирования: lang-list
Нажмите для просмотра прикрепленного файла

К сожалению, мне об Eclipse достаточно знания того, что он из РЕАЛЬНО подающего в моих глазах большие надежды редактора, быстро превратился в неуправлемое глюкало растаскиваемое по разным веткам .

Такие простейшие действия реализуются на скриптах любого приличного редактора. А за, буквально, минуту даже на готовом механизме тагов, или фильтрации текстов, такое к древному, как дерьмо мамонта, Multiedit прикручу. Но TODO веду отдельно.
Чем хотели удивить? Все уже придумано до создателей монстрообразных IDE.


В любой хоть сколь-нибудь вменяемой оболочке всевозможных выделений чего угодно можно добавить море.

А щелкнув по строчке в табличке мы сразу оказываемся в точке в исходниках где этот коммент расположен. А еще щелкнув можем создать даже целую задачу в менеджере задач и поставить приоритет этой задаче и проч. и проч.
Сидеть по 20 лет на одном тулсе это не предмет гордости.




Этот colorer как раз для Eclipse и предназначен.

Все абсолютно аналогично.

Не на одном и том-же, а на РАЗВИВАЮЩЕМСЯ и живущем и ВОСТРЕБОВАННОМ потребителями платящими за него деньги все эти годы. Для "бесплатных" инструментов, сие, понятно, не характерно - сделали, бросили, или в лучшем случае утащили в отдельые ветки, причем в удручающем большинстве случаев не понимая, что творят

Тем печальнее для Eclipse, что в базе несколькими символами нельзя дописать в описании языка, то, что нужно подсветить и нужны "colorer-ы", блин. А так, вообще. Eclipse жаль - задумка была отличная.