Хороший стиль кодирования на С/С++, и готовые программы конвертации в него. Опции

[Serhiy_UA]

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

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

[AlexandrY]

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

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

[Serhiy_UA]

к 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...

[AlexandrY]

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

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

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

[zltigo]

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

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

[AlexandrY]

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

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

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

[zltigo]

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

Аналогично.

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

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

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

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

[AlexandrY]

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

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

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

[zltigo]

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

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

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

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

[AlexandrY]

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

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

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

Ну, реальная жизнь вашими use-case не ограничивается..

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

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

[zltigo]

Я скачал вашу программу по ссылке. Хоть вы и даете почему-то ссылки только на коммерческие сомнительные продукты.

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

Она делает не намного больше чем умеет Total Commander.

Да ну

Стилизованные файлы отмечает как отличающиеся.

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

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

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

Почему же, именно мой use-case вы и привели в пример.

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

[jcxz]

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

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

[Dog Pawlowa]

"Обрати внимание! Здесь есть временная вставка!"

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

#ifdef UART0_USED_FOR_RS485
....
#endif

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

[jcxz]

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

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

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

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

[AlexandrY]

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


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

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

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

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

[zltigo]

А в курсе что в Eclipse..

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

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

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

там такое выделение называется to-do comment.

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