Separazione del codice in file più piccoli in C

Suggerirei di digitare tutte le strutture e inserire tali dichiarazioni in un file di inclusione separato. Quindi definisci tutte le tue istanze reali delle strutture in qualunque cosa il tuo file "principale" finisca per essere. Quindi, includi semplicemente l'intestazione e dichiara le istanze necessarie extern negli altri file. Il linker si occuperà di confrontare tutti i riferimenti, non dovrebbe esserci alcun problema.

Esiste una terza alternativa ibrida, che consiste nel mettere ciascun globale nel proprio modulo e scrivere funzioni per supportarlo. Questo ti dà il vantaggio OOP-y di tutto il codice relativo alla separazione della variabile in un punto e molto più facile da riutilizzare altrove se necessario. Mettere le funzioni di supporto nell'intestazione in modo che possano essere sottolineate invece di forzare le chiamate ti dà i vantaggi di avere tutto in un unico file.

Ad esempio:

// foo.h

typedef int FooType;

extern FooType foo_global_do_not_use_directly;

static inline void foo_init() {
    foo_global_do_not_use_directly = 0;
}

static inline void foo_set(FooType new_foo) {
    foo_global_do_not_use_directly = new_foo;
}

static inline FooType foo() {
    return foo_global_do_not_use_directly;
}

.

// foo.c

// Always include the header even if you're not using a
// typedef so it gets compiled at least once.
#include "foo.h"

FooType foo_global_do_not_use_directly;

Ovviamente, dovrai passare attraverso il resto della tua fonte e regolare ogni utilizzo dei globali per utilizzare le funzioni invece di fare riferimento direttamente ai simboli. Nel processo, potresti trovare altre cose che vengono ripetute ripetutamente e meritare di essere le loro funzioni, il che potrebbe avere dei benefici in fondo se dovessi cambiare il modo in cui queste operazioni funzionano.

Vado con la tua Opzione 1: lascia i globali in un unico file dove è facile trovarli .

Come hai notato nei commenti, questo non è OOP . Le "regole di OOP" (sebbene molto buone in senso generale) non si applicano necessariamente a un progetto piccolo su un dispositivo incorporato.

5000 righe in un file sono un problema con cui lavorare. 5000 linee in una soluzione sono piuttosto piccole. Se hai già spostato le altre cose, è probabile che ciò che rimane non sia poi così grande. Se lo dividi, passerai molto tempo a cercare quello globale che desideri modificare.

Ricorda, l'obiettivo è mantenere il codice organizzato in modo da poter seguire chiaramente la struttura, apportare le modifiche necessarie (e comprenderne l'impatto) e separare "cose che cambiano" da "cose che non lo fanno".

OOP è il modo comune per raggiungere questo obiettivo su computer moderni di uso generale. Non è l'unico modo per fare le cose, e potrebbe non essere il modo migliore per un dispositivo embedded con memoria limitata.