Я относительно новый программист на C, и я заметил, что многие соглашения с других языков ООП более высокого уровня не совсем верны на C.
Можно ли использовать короткие функции, чтобы ваше кодирование оставалось организованным (хотя оно, вероятно, будет вызвано только один раз)? Примером этого может быть 10-15 строк в чем-то вроде void init_file(void), а затем сначала вызвать его в main().
Я бы сказал, не только это нормально, но и вообще поощряется. Просто не надо чересчур фрагментировать мысль, создавая мириады крошечных функций. Попытайтесь обеспечить, чтобы каждая функция выполняла единую связную, хорошо... функцию с чистым интерфейсом (слишком много параметров могут быть намеком на то, что функция выполняет работу, которая недостаточно отделяется от нее вызывающего).
Кроме того, хорошо известные функции могут служить заменой комментариев, которые в противном случае были бы необходимы. Помимо обеспечения повторного использования, функции также могут (или вместо этого) предоставлять средства для организации кода и разбивать его на более мелкие единицы, которые можно более легко понять. Использование функций таким образом очень похоже на создание пакетов и классов/модулей, хотя и на более тонком уровне.
Да. Пожалуйста. Не записывайте длинные функции. Напишите короткие, которые делают одно и делают это хорошо. Тот факт, что их можно назвать только один раз, прекрасен. Одно из преимуществ заключается в том, что если вы хорошо назовете свою функцию, вы можете избежать написания комментариев, которые со временем будут не синхронизироваться с кодом.
Если я могу взять на себя смелость сделать некоторые цитаты из Code Complete:
(Эти причины детали были сокращены и в пунктах перефразированы, для полного объяснения см. полный текст.)
Действительные причины для создания обычной
Обратите внимание, что причины перекрываются и не должны быть независимыми друг от друга.
Уменьшить сложность. Самая важная причина для создания подпрограммы - уменьшить сложность программы (скрыть детали, чтобы вам не нужно было думать о них).
Внедрить промежуточную, понятную абстракцию. Включение раздела кода int o с использованием названной подпрограммы является одним из лучших способов документирования своей цели.
Избегать дублирования кода - самая популярная причина для создания подпрограммы. Экономит место и упрощает обслуживание (нужно только проверить и/или изменить одно место).
Скрыть последовательности. Это хорошая идея, чтобы скрыть порядок, в котором события обрабатываются.
Скрыть операции с указателями. Операции указателя, как правило, трудно читать и подвержены ошибкам. Изоляция их в подпрограммах смещает фокус на намерение операции, а не на механику манипуляции с указателем.
Улучшить переносимость. Используйте процедуры, чтобы изолировать непереносимые возможности.
Упростить сложные логические тесты. Включение сложных логических тестов в функцию делает код более удобочитаемым, поскольку детали теста находятся в стороне, а описательное имя функции суммирует цель тесты.
Повысить производительность. Вы можете оптимизировать код в одном месте, а не несколько.
Чтобы гарантировать, что все процедуры невелики? - Нет. С таким большим количеством веских причин для ввода кода в рутину это необязательно. (Это тот, который брошен в список, чтобы убедиться, что вы обращаете внимание!)
И одна заключительная цитата из текста (глава 7: Высококачественные подпрограммы)
Один из самых сильных ментальных блоков для создание эффективных подпрограмм нежелание создавать простую рутину для простой цели. Построение целая рутина, чтобы содержать два или три строки кода могут показаться overkill, но опыт показывает, как полезной хорошей рутиной может быть.
Если группу утверждений можно рассматривать как вещь - тогда сделайте их функцией
Я думаю, что это более чем нормально, я бы порекомендовал его! короткие легко обоснованные правильные функции с хорошо продуманными именами приводят к коду, который более самодокументирован, чем длинные сложные функции.
Любой компилятор, который стоит использовать, сможет встроить эти вызовы для генерации эффективного кода, если это необходимо.
Функции абсолютно необходимы, чтобы оставаться организованными. Вы должны сначала спроектировать проблему, а затем в зависимости от различных функций, которые вам нужно разбить на функции. Некоторая часть кода, которая используется несколько раз, вероятно, должна быть записана в функции.
Я думаю, сначала подумав о том, какая у вас проблема, сломайте компоненты, и для каждого компонента попробуйте написать функцию. При написании функции проверьте, есть ли какой-то сегмент кода, делающий то же самое, затем разбивайте его на подфункцию или, если есть дополнительный модуль, он также является кандидатом на другую функцию. Но в какой-то момент эта работа должна прекратиться, и это зависит от вас. Как правило, не делайте слишком много больших функций и не слишком маленьких функций.
При построении функции, пожалуйста, подумайте, что конструкция имеет высокое сцепление и низкое сцепление.
EDIT1:
вы можете также рассмотреть отдельные модули. Например, если вам нужно использовать стек или очередь для какого-либо приложения. Сделайте его отдельным модулем, функции которого могут быть вызваны из других функций. Таким образом, вы можете сохранить часто используемые модули повторного кодирования, программируя их как группу функций, хранящихся отдельно.
Я следую нескольким рекомендациям:
Каждый из этих принципов в какой-то момент потребует, чтобы функция была разбита, хотя я полагаю, что # 2 может означать, что две функции с прямым кодом должны быть объединены. Несколько более обычным является то, что называется методом извлечения метода, чем фактически разделение функции на верхнюю и нижнюю половину, потому что обычной причиной является извлечение общего кода для вызова более одного раза.
# 1 весьма полезен в качестве помощи для принятия решений. Это то же самое, что сказать, как и я, "никогда не копировать код".
# 2 дает вам повод разбить функцию, даже если повторного кода нет. Если логика принятия решения проходит определенный порог сложности, мы разбиваем его на большее количество функций, которые принимают меньше решений.
Это действительно хорошая практика для реорганизации кода в функции, независимо от используемого языка. Даже если ваш код короток, он сделает его более читаемым. Если ваша функция довольно короткая, вы можете рассмотреть ее вложение.