Comments 21
Не могу одного понять: если вы считаете это правило ничем не обоснованной IT муштрой, и не было утилиты которая его проверяет и энфорсит, зачем было нужно её писать вместо того чтобы правило игнорировать и саботировать?
del
зачем было нужно её писать ...?
Потому что могу.
Как задача из литкода.
зачем было нужно её писать вместо того чтобы правило игнорировать и саботировать?
Саботирует работу как раз тот, кто придумывает все эти нелепые правила code style.
Утилита prototype_check производит тщательный контроль создает два текстовых файла, чтобы увидеть недочёт. Показывает какие именно static функции обитают не на своём месте.
Непонятно, зачем останавливаться на полпути :) Нужно создавать diff файл, который можно применить (возможно, прямо самой утилитой) и исправить проблему.
Это которая по счету статья о корпоративных костылях от этого автора? Хотелось бы уже узнать название этой чудесной конторы)
Почему именно "костыль"?
Можно подумать, что существует какая-то широко известная утилита, которая проверяет порядок объявления и определения static функций в Си коде.
Я, между прочим, исследование проделал. И пришёл к выводу, что такой утилиты не существует.
Поэтому и пришлось мне ее написать.
Надеюсь, это был сарказм. Если нет, то поясняю: этого нет, потому что это никому не нужно, кроме "организаций", где важно правильно переложить бумажку, а не сделать продукт.
Всё же мой вопрос был про название этой чудесной "организации". Ответите? )
такой утилиты не существует.
Потому что за пределами вашей конторы она никому не нужна?
У вас в организации есть требование: «Последовательность объявления static функций должна совпадать с последовательностью определения static функций в конце *.с файла.»
Нет варианта "Запрещены объявления static функций".
Стилистический анализатор: синхронизация объявлений и определений static функций