Есть какие то гайдлайны оформления C?

Есть ли какой нибудь единый codestyle и правила

Единых нет, для каждого проекта будут свои правила.

когда делать return, а когда обращаться по указателю?

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

Насколько глобальные переменные в маленькой утилите плохи?

Ровно на величину своей плохости.

Есть ли какой нибудь единый codestyle

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

правила когда делать return, а когда обращаться по указателю?

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

Насколько глобальные переменные в маленькой утилите плохи?

Ничего тут плохого нет. Плохо будет тогда когда ты начнёшь её значение дрыгать через extern в других файлах не потому что так задумано, а просто потому что вот сейчас вот тут надо её значение, а интерфейса к этому делать в лом.

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

Стараться не совать переменные в заголовочные файлы.

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

Касательно глобальной переменной даже в большой программе, если она только для 1 файла то всё хорошо в принципе. Так как полученный объектный файл это изолированный объект.

P.S. Я не программист если чё =)

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

А у меня вообще всего 250 строк

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

Тут вообще нечего думать. Понадобятся неглобальные - перепишешь хоть заново весь код.

MISRA Вряд ли тебе это прям необходимо. Но какое-то представление о том «что такое хорошо и что такое плохо», получишь.

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

Я на глобальных пкременных буферы сделал

Так все и делают. Для всей программы (на много файлов) делают интерфейс, для одного файла или одной единицы сборки (файла) дрыгают напрямую.

чтобы меньше аллоцировать и освобождать память.

Это хорошо.

То есть программа пропарсила аргументы, выделила память и пошла работать

Так и надо.

Учитывая что ты используешь C, который недоязык, проще и надёжнее выделять статически (если есть такая возможность, т.е. размер заранее известен и константен), чтобы, действительно, на писать ручных вызовов malloc и free и не иметь возможности в них ошибиться, с этой позиции это правильно.

А вообще же, про глобальные переменные всегда полезно провести мысленный эксперимент:

• что если ты захочешь сделать свою программу многопоточной?
• что если ты захочешь встроить её в другую программу, где она будет вызываться в непредсказуемые моменты и, возможно, в нескольких экземплярах?

Тут возможны только 3 варианта: либо о глобальных переменных навсегда забывают, либо сознательно принимают решение «и так сойдёт, зато просто», либо отвечают «не захочу», расписываясь в некомпетентности.

Если интересно, вот код.

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

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

Ты наверное сомневался в типа в этом void generate_window(float *out, int n); и подобном. Но ты выше после аллокации window проверяешь указатель и можно в функции уже его не проверять и соответственно возвращать ничего не надо. Пока эта функция чисто внутренняя и не хочет потом стать библиотечной то всё ок Код ты выравнивал чисто руками, это видно. Читается нормально. На мой поверхностный любительский взгляд всё складно. Всякая мелочь на любителя на в счёт.

w2midi is a program which transform JACK wave stream to MIDI.

transformS! Третье лицо, единственное число.

to MIDI

Но зачем? Под линуксом же оно не проигрывает я без бубна. А телефоны с пищалками уже всё.

Подключаешь программу к синтезатору, играешь на гитаре и слушаешь синтетическиц звук

Вот называется я скопипастил с другого моего текста :)

Я потом видос запишу и может быть в виде новости сделаю

Это не стандарт оформления. Это скорее набор дополнительных ограничений на синтаксис.

Исправил, спасибо!

https://man.openbsd.org/style.9

Я уже по ходу использую стиль Кеннигана и Ритчи

Прошу прощения что не в тему, но киньте пожалуйста в меня мануалом, как правильно обновить уже установленного опёнка (7.0 -> 7.1 в данном случае).

Одной командой: https://man.openbsd.org/sysupgrade.8

Благодарю. :)

good codestyle examples

MISRA Ltd. «Guidelines for the Use of the C Language in Critical Systems» (2013)

CERT C coding standart

NASA C style

Интересно… Почитаю, спасибо!

Есть ли какой нибудь единый codestyle

GNU Coding Standards

либо отвечают «не захочу», расписываясь в некомпетентности

Любая программа обязана иметь возможность быть многопоточной? Вы уверены?

Я такого не писал, это ваши бредни.

Я процитировал часть Вашего утверждения. Можете пройти по ссылке и сверить посимвольно.

Чтобы мою прогу сделать многопоточной, нужно ее запустить несколько раз и подключить в JACK несколько устройств!

Я не писал не то что вы процитировали, а то что написали вы. Я не писал что любая программа обязана иметь возможность быть многопоточной. Будьте внимательней, пожалуйста.

Тогда как трактовать логическое построение

что если ты захочешь сделать свою программу многопоточной?
...
Тут возможны только 3 варианта: ..., либо отвечают «не захочу», расписываясь в некомпетентности.

?

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

sickless же! Но без фанатизма.

Хорошо, спрашиваю прямо.

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

Тогда как понимать то сообщение? К чему относится процитированное мною «не захочу»? Оно не разворачивается в «не захочу сделать свою программу многопоточной или встроить её в другую программу»?

Самый первый гайдлайн: забыть о C89 как о страшном сне и использовать хотя бы C99 с #pragma once, декларациями переменных прямо в for, bool вместо int, __VA_ARGS__.

Для вещей вроде «когда обращаться по указателю» и «использовать ли глобальные переменные» рекомендуется иметь свою голову на плечах. Уж горький опыт «пробрасывания аргументов через стек вызовов» в чужом коде должен был бы навести на мысль, почему глобальные переменные не всегда зло.

И вообще, загляни внутрь coreutils, vim, bash — ни разу не образцы офигенного кода, но ими пользуются и заглядывают в код миллионы людей, и всем норм.

C, который недоязык

Оп, а вот и неосиляторы подтянулись. Что ты имеешь против безграничного могущества C?

что если ты захочешь сделать свою программу многопоточной?

В этих случаях рекомендуется открыть для себя __thread. И, кажется, в C11 для этого даже что-то стандартное появилось. В любом случае, в огромном количестве случаев в глобальных переменных оказывается shared immutable state (aka «конфигурация», «флажки командной строки»), таскать который сквозь стек вызовов — мартышкин труд.

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

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

Нафиг декларировать переменные в for и использовать bool? А вот pragma one вещь интересная…

Нафиг декларировать переменные в for и использовать bool?

Затем, что программа более читаемой становится. С int ты ещё подумаешь, флаг это или реально целое значение, а с bool всё ясно (да, я в курсе, что под капотом это тоже целое число, но тут программист явно объявил, зачем оно нужно, и это важно).

Ну и кроме <stdbool.h> есть ещё и <stdint.h>, и вот это уже точно не украшательство, а суровая необходимость, когда надо работать с двоичными файлами или сетевыми пакетами…

Ну stdint.h я иногда пользуюсь, когда необходимо строгое количество бит отмерить