Как лучше писать Опции

[npopok]

Keil mVision.Соответственно, есть куча разных функций.Одни для одного,другие для другого, где то они пересекаюся и не редко.В общем, как обычно.Вот вопрос-стоит ли собирать их в разные си файлы и делать кучу extern-ов, или лучше все-таки без особой необходимости этого не делать.Может, надо искать золотую середину?Есть ли какие-нибудь критерии,кроме здравого смысла? На что это влияет?Спасибо

[npopok]

Модульность-это хорошо.Я это, безусловно, пинимаю.Такой вопрос-если я забью на модульность и совместимость, получу ли я прирост скорости или там свободного места?

[MrYuran]

Такой вопрос-если я забью на модульность и совместимость, получу ли я прирост скорости или там свободного места?

Встречный вопрос: а засчёт чего?
Компилятор транслирует исходники функций в объектный код, линкер собирает из объектов файл прошивки. По большому счёту, им без разницы, в одном файле находятся функции или в 10. (20,50).
Скорость и свободное место - понятия взаимоисключающие.
Нужна скорость - inline и unrolling, соответственно теряем место.
Не хватает места - обратная ситуация, приходится жертвовать скоростью.

[Сергей Борщ]

Встречный вопрос: а засчёт чего?

Например, компилятор может самостоятельно встроить функции, используемые только один раз и объявленные как static. Экономия на командах вызова, передаче параметров, прологе/эпилоге.
Некторые функции содержат кода меньше, чем накладные расходы на ее вызов. Или функции-обертки, которые при встраивании вообще не генерят кода. Безусловное встраивание таких функций дает выигрыш и в объеме и в скорости. Если функция не static и тело ее в другом файле - компилятор не сможет ее встроить. Таким образом, некоторые функции модуля целесообразно выносить из .c в .h, добавляя к ним квалификатор static. Они могут потянуть за собой другие. Если же функция большая и используется дважды - получим обратный эффект. Такая оптимизация в любом случае происходит при помощи программиста, и порой в угоду читабельности и модифицируемости кода стоит некторые участки оставить неоптимальными. В противном случае придем у ручной правке ассемблерного кода после компилятора.