Да, кстати, капсом я обертки не выделяю
о_О
Я пишу их с заглавной буквы.
Кто то использует _ перед именем обертки, кто-то — другие обозначения. Тут тоже есть свобода выбора :)
О_о
Я не нес в своей статье посыл «Пишите только так и никак иначе» — каждый волен выбирать, какого стиля придерживаться. Те рекомендации по оформлению кода, что я привел — сборка наиболее часто используемых принципов как из проектов компании, где я работаю, так и из opensource проектов.
У новичка, читающего данную статью, появится представление о том, как обычно делают более опытные ребята в самых разных проектах :)
А по поводу оберток — они нужны не в эксплуатации — конечный пользователь не будет смотреть логи работы программы -, а в отладке. Надо же тестерам и разрабам понимать, что и где упало в случае ошибки.
Да, возможно. Выбрал довольно абстрактную тему для статьи — сложно охватить все и разом. Правда, inline я вижу постоянно, а те же volatile и restrict — довольно редко, даже в тех местах, где их использование напрашивается.
Скажем так, узнать про inline проще, чем про restrict и volatile — вот я и решил это упомянуть :)
А register — да, потихоньку выходит из использования. Тем не менее, иногда — полезная вещь.
В крупных проектах (во всяком случае, в тех, в которых я участвовал) все необходимые библиотеки (включая libc-библиотеки) содержатся в исходниках и компилируются при сборке.
То есть, в проекте присутствует только одна версия библиотеки. Хочешь другую — нужно озаботиться этим и установить её в проекте.
В паре наших проектов видел такую практику: в папке с библиотекой хранятся исходники нескольких её версий в архивах, а в файле конфигурации сборки есть параметр, отвечающий за версию библиотеки. Указываешь версию и при сборке она будет разархивирована и собрана. Не знаю, насколько это часто используется, но можно рассмотреть как вариант.
Дельное замечание.
На самом деле, в си есть такая вещь, как предварительное объявление функции.
То есть, если ты уверен, что это будет полезно для читаемости, ты можешь объявить переменную в начале, а инициализировать в коде, но так же с объявлением типа.
Например:
int foo;
/* ... спустя n строк в той же области видимости...*/
int foo = VALUE_FOR_FOO;
Конечно, это противоречить пункту о инициализации при объявлении, но каждый сам решает, чему отдавать приоритет.
о_О
Я пишу их с заглавной буквы.
Кто то использует _ перед именем обертки, кто-то — другие обозначения. Тут тоже есть свобода выбора :)
О_о
У новичка, читающего данную статью, появится представление о том, как обычно делают более опытные ребята в самых разных проектах :)
А по поводу оберток — они нужны не в эксплуатации — конечный пользователь не будет смотреть логи работы программы -, а в отладке. Надо же тестерам и разрабам понимать, что и где упало в случае ошибки.
Скажем так, узнать про inline проще, чем про restrict и volatile — вот я и решил это упомянуть :)
А register — да, потихоньку выходит из использования. Тем не менее, иногда — полезная вещь.
То есть, в проекте присутствует только одна версия библиотеки. Хочешь другую — нужно озаботиться этим и установить её в проекте.
В паре наших проектов видел такую практику: в папке с библиотекой хранятся исходники нескольких её версий в архивах, а в файле конфигурации сборки есть параметр, отвечающий за версию библиотеки. Указываешь версию и при сборке она будет разархивирована и собрана. Не знаю, насколько это часто используется, но можно рассмотреть как вариант.
А вообще есть clib, но я с ней не работал, ничего сказать о ней не могу:)
Ну или, вот это менее популярное решение.
С Rust я пока еще не знаком, с Go недавно начал возиться. Пока все очень нравится — система импорта пакетов после сей не перестает меня радовать :)
На самом деле, в си есть такая вещь, как предварительное объявление функции.
То есть, если ты уверен, что это будет полезно для читаемости, ты можешь объявить переменную в начале, а инициализировать в коде, но так же с объявлением типа.
Например:
Конечно, это противоречить пункту о инициализации при объявлении, но каждый сам решает, чему отдавать приоритет.