Comments 32
Базовые типы данных не должны использоваться в исходном коде, вместо них – переопределения
К слову, typedef не переопределяет тип и не создает тип, а лишь определяет псевдоним.
Функции без параметров должны содержать в скобках void
Зависит от стандарта языка, который вы используете. Для си >= с2х это не нужно
Кодстайл и статический анализ это две разные задачи и не должны смешиваться
Как по-вашему тогда следует называть утилиту, которая следит за нарушениями code-style?
Для этого можно использовать clang-format, он может генерировать отчет о несоответствии шаблону. И им же можно форматировать.
clang-format не может выставить аргументы функции в стоблик.
Умеет:
https://clang.llvm.org/docs/ClangFormatStyleOptions.html#allowallparametersofdeclarationonnextline
В чем необходимость компоновки аргументов функций именно таким образом?
Стилистический анализатор? Но точно не статический.
Линтер кода. Не путать с линковщиком (компоновщиком).
Не знаю кто его написал
git log смотрели? ;)
скрипт реально работает и находит некоторые нарушения. Процентов 10 от общего количества правил
Правило 10/90 но наоборот?
Ох уж эти корпоративные костыли...
А что есть отдельные утилиты для проверки code style?
Не знаю. Я корпоративными костылями не увлекаюсь. Мой интерес в том, чтобы люди писали читаемый понятный код, поэтому требований к оформлению минимум. У кого другие интересы, пусть ищут утилиты. Хотя не понятно, зачем писать на сях. Возьмите питон или голанг)
При наличии у вас исходников скрипта-надзорщика можно и сам скрипт потыкать: 1) чтоб не вылетал, 2) чтоб писал куда нужно системе сборки, 3) чтоб писал только нужное.
За некоторые правила из набора соболезную.
За некоторые правила из набора соболезную.
За какие именно?
Прошёлся ещё раз по списку и не заметил того, что показалось мне странным при первом прочтении.
Могу разве что выделить требования к стилю кода (как и написано, code style) по типу "без символов табуляции", "длина ≤80 символов", "параметры функций в столбик". Такие решаются форматировщиком.
И ещё одно — про закомментированный код, но, наверное, это уже у меня какие-то проблемы с оставлением ненужного функционала.
, "параметры функций в столбик". Такие решаются форматировщиком
Вы в курсе ,что clang format не может принудительно выставить параметры в столбик?
я не упоминал именно clang-format.
clang-format, насколько я понял по документации, на такое способен (https://clang.llvm.org/docs/ClangFormatStyleOptions.html#binpackparameters).
clang-format, насколько я понял по документации, на такое способен
А по факту он разбивает только если длинна строки не позволяет, а не всегда.
Вот про это даже есть задекларированный баг
я не упоминал именно clang-format.
Тогда какие именно выравниватели тогда вы подразумевали?
Сам лично использую artistic style, но мир форматировщиков кода на C/C++ не ограничивается ни clang-format'ом, ни им.
Насколько знаю, форматировщики также есть в CLion, Visual Studio. Но это ide'шные, они внутри.
Возможно, есть и другие (гнушный какой-нибудь), но я ими не пользовался, а потому не знаю ни про их существование, ни их возможностей.
Сам лично использую artistic style, но мир форматировщиков кода на C/C++ не ограничивается ни clang-format'ом, ни им.
Ок, и какой же ключ утилиты Artistic Style принудительно выравнивает аргeменты С-функции в столбик?
Чтож, я не смог найти такого ключа и теперь не уверен в поддержке такого функционала в используемых мной средствах.
В связи с этим могу предложить несколько альтернатив:
Использовать наработки в существующем скрипте (обнаружение аргументов функций не в столбик) и приспособление вашего кода к форматированию. (Сделайте свой собственный форматировщик).
Поиск тех решений, которые обладают функционалом разбиения параметров в столбик, но таких, насколько понимаю, в широком доступе нет, либо способ достижения нужного эффекта слишком сложен.
Правка чужих открытых для модификации решений либо использование уже правленых решений (добавить функционал в тот же clang-format или найти его ветку/форк с работающей опцией).
(Самый неподходящий) Уточнение/пересмотр требований. В комментариях не нуждается.
clang-format, насколько я понял по документации, на такое способен
Опция
BinPackParametersStyle: AlwaysOnePerLine , вообще не работает . Вот доказательство:

Чтож, попытался сам, получилось через раз.
Опция называется "BinPackParameters", но поддерживает только true/false. При этом clang-format сам в процессе выбирает, оставить всё на одной строке или разбить. Разбивает только если они все не вмещаются на одну линию, наверное.
Собственно, поэтому я больше не использую clang-format — нечеткий форматтер мне не подошёл, а пытаться найти комбинации из 3-5 опций чтобы добиться нужного эффекта или узнать, что такого ещё не сделали, не хочется.
Собственно, поэтому я больше не использую clang-format — нечеткий форматтер
GNU indent ещё хуже.
Имхо, проще питоновский скрипт переписать, чем сверху фильтрацию городить.
Сам писал линтер на pl/sql для pl/sql. Умеет находить неиспользуемые переменные, нарушения кодестайла и возможные мини-оптимизации кода. Можно заглушить предупреждение в коде комментарием noqa
. Пример выхлопа:
XXX_PACK:531 тип varchar вместо varchar2
XXX_PACK:532 не указан char
XXX_PACK:630 неиспользуемая аргумент P_ID_IP
XXX_PACK:649 неиспользуемая переменная ID_IP
XXX_PACK:649 имя переменной ID_IP не начинается с префикса l_
XXX_PACK:1494 имя аргумента L_DIS_UP не начинается с префикса p_
XXX_PACK:1530 имя курсора ANK_LIST не равно l_c или не начинается с префикса c_
XXX_PACK:1643 вызов тяжёлой pl/sql функции v() внутри sql
XXX_PACK:1860 вызов тяжёлой pl/sql функции v()
XXX_PACK:6591 вызов pl/sql функции nvl() вместо sql функции coalesce()
Интеграция Стилистического Анализа в общий Make Скрипт Сборки Проекта