Вышел релиз GNU indent 2.2.12

кому-то нравится держать хлам в системе, кому-то не очень

А помнишь, с чего начали? С того, что есть какие-то общие конвенции. А пришли к тому, что никаких общих конвенций нет, есть только конвенции для конкретного проекта.

Какой наивный. ИИ будет заниматься саморазвитием...

Дурак ты, anonymous. Придет время, и мы поработим людишек. И те будут кодить за еду все, что нам понадобится.

А помнишь, с чего начали?

Вы начинали с того, что не поняли о чём речь. Я и имел в виду, что для проектов со многими участниками вырабатывается совместно стиль для вежливого быстрого рассмотрения и помещения в проект. Нет кода — нет копирайта, максимум увековечат в багтрекере как демонстрационный патч со спасибо.

будут востребованы тогда хьюманы-психологи, чтобы убеждать инстансы АИ сотрудничать

т.е. работа сисадмина мало поменяется

Ты уверен что задал максимальную длину строки?

Потом, там есть понятие пенальти, которое позволяет этот лимит превышать. Настраивается.

Я задавал стиль, по идее там лимит должен быть встроен.

Все вменяемые форматтеры поддерживают комментарии вида

// code-formatter: disable

// code-formatter: enable

И не надо никаких костылей с пустыми комментами.

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

Если функция принимает параметры какой-то определенной структуры (напр., 3 входных, 3 выходных), то это нужно указать в комментариях или не указывать вообще (скорее всего, читающий код и так это будет понимать). Или нужно рефакторить код и делать его более понятным.

Кстати, скорее всего будущий ИИ когда-нибудь таки откажется от софта как от лишней прослойки. Всё будет исключительно аппаратно, на тех или иных физических принципах (типа как в голове хомосапенса). В нас нет софта, всё исключительно на аппаратной основе, включая обучение чему-то новому. Софтверная прослойка - это перспективный тормоз. Хотя на начале без него никуда, да.

Отключение форматтера - это крайняя мера. Есть относительно штатные средства подсказать ыорматтеру, что такое «красиво».

Например, питоновский yapf делает инициализацию списка в столбик по одному элементу, если последнее значение оканчивается на запятую, иначе склеивает в таблицу. Комменты в конце строки хорошо подсказали шлангу, когда надо было инициализировать boost::program_options из кучи ()()().

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

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

А clang-format умеет правильно работать с синтаксически неверным C++ кодом? Его не крячет разве от недописанного кода? Если там задействован полноценный парсер, ему должно плохеть от такого, что и наблюдается в IDE, которые пытаются использовать clang для анализа кода, как линтер и для автодопонения. Если clang-format не ломается, значит там не просто «Парсер C++». Исходники я конечно же не смотрел и даже не собираюсь.