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

[npopok]

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

[MrYuran]

Обычно всегда стараюсь чётко разделить программу на модули, как можно более автономные. Функции, описанные в модулях, выносим в h-файл, и в других модулях его подключаем. Всё как обычно. Переменные тоже желательно разделить, для внутримодульного употребления - static.
Да это и не только для АРМ и Кейла, а вообще нормальный стиль программирования.
Потом я беру, к примеру, модуль Indicator.c, перетаскиваю в новый проект и он без единой настройки сразу работает.
А чтобы не было "кучи extern-ов", нужно в модуле группировать данные и функции для работы с этими данными. Чтобы не было глобальных пересечений и взаимосвязей.

[scifi]

Обычно всегда стараюсь чётко разделить программу на модули, как можно более автономные. Функции, описанные в модулях, выносим в h-файл, и в других модулях его подключаем. Всё как обычно. Переменные тоже желательно разделить, для внутримодульного употребления - static.

+1. Сам к этому пришёл, основываясь на горьком опыте. Программы стали значительно более читаемыми. И больше не надо держать в голове всё это хитросплетение из глобальных переменных и функций.
Ещё одно правило - комментарий к каждой функции.

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

Забивание на модульность приведёт к менее читаемой программе, а в ней потери скорости/памяти возникнут сами собой из-за бардака. И вообще, начинать оптимизировать надо только после того, как необходимость оптимизации была доказана измерениями. Иначе это пустая трата времени. Конечно, это не отменяет того, что выбираемые решения и алгоритмы должны изначально быть реалистичными (к примеру, таблица синусов на 100 кБайт не влезет в МК с 32 кБайтами).