Struttura delle cartelle per un progetto C [chiuso]

Question

Struttura delle cartelle per un progetto C [chiuso]

#1 da (1 voti)

-1

Mi chiedo quale sia la struttura di cartelle consigliata per un progetto C. Ho letto diversi post sull'utilizzo di src, include, test, crea cartelle. Ma cosa succede se voglio strutturare il progetto in moduli?

Devo usare una struttura come:

src/
    core/
        main.c
        sysinit.c
        interrupts.c
        ...
    module1/
        file1_1.c
        ...
    module2/
        file2_1.c
        ...

include/
    core/
        main.h
        sysinit.h
        interrupts.h
        ...
    module1/
        file1_1.h
        ...
    module2/
        file2_1.h
        ...

o in questo modo:

core/
    src/
        main.c
        sysinit.c
        interrupts.c
    include/
        main.h
        sysinit.h
        interrupts.h
        ...
module1/
    src/
        file1_1.c
        ...
    include/
        file1_1.h
        ...
module2/
    src/
        file2_1.c
        ...
    include/
        file2_1.h
        ...

Se i due modelli precedenti non sono raccomandati, quali sono le convenzioni / schemi comunemente usati?

c code-organization project-structure

posta Mat.R 29.09.2018 - 08:46

fonte

1 risposta

Leggi altre domande sui tag c code-organization project-structure

Come garantire la separazione e le dipendenze interne tra i livelli architetturali in Python? Come modellare entrambe le relazioni?

score 1 · Accepted Answer

Entrambi sono possibili, quindi se trovi qualche motivo per utilizzare un approccio anziché l'altro, vai avanti.

Vorrei utilizzare il secondo approccio (le directory di livello superiore sono core, module1, module2, ecc.) se i diversi moduli sono in qualche modo utili da soli (tranne forse il modulo "core", se ogni altro modulo dipende da esso. )

Se tutti i moduli dipendono l'uno dall'altro e i singoli moduli sono inutili senza gli altri moduli, utilizzare il primo approccio (le directory di livello superiore sono src, include, ecc.)

Esempio 1:

Hai 4 moduli per un piccolo sistema di gestione delle relazioni con i clienti (CRM) offline:

"infrastruttura": contiene la registrazione, i tipi di dati di base e alcune funzioni per astrarre le dipendenze dalla piattaforma
"dominio": contiene la logica aziendale
"gui" - contiene la GUI e si basa su "infrastruttura" e "dominio"
"cli" - contiene un'interfaccia a riga di comando, anch'essa basata su "infrastruttura" e "dominio".

In questo caso, utilizzerei il primo approccio (le directory di livello superiore sono src, include, ecc.) Le diverse parti non possono essere utilizzate separatamente, sono tutte collegate. Forse la cartella "infrastruttura" viene compilata senza le altre cartelle, ma come si può usare la libreria .. risultante?

Esempio 2:

Hai 5 moduli per un sistema di gestione documenti che legge file arbitrari e li converte in un formato comune:

base: contiene i tipi di dati di base e il supporto della piattaforma
fogli di calcolo: consente di analizzare i fogli di calcolo Excel e OpenOffice
pdfparser - può leggere file PDF e PS
imagescanner - legge i file JPG, PNG e TIFF per eseguire l'OCR con loro
conversiontools - può convertire 90 diversi formati di file in formati di file supportati più comuni

In questo caso utilizzerei il secondo approccio (le directory di livello superiore sono core, module1, module2, ecc.) - Tutti i moduli possono essere usati standalone e sono utili (tranne che per il modulo "base", ovviamente.) I diversi i moduli sono in qualche modo disaccoppiati e metterli in directory separate comunica chiaramente a tutti che questa è una decisione di progettazione di base.

Quando crei degli esempi, è bello trarre davvero esempi realistici. Questo rende la risposta molto più ovvia. I cattivi esempi sono così comuni, però. Un vero progetto non ha mai moduli chiamati "module1" e "module2". Senza sapere quali sono i moduli, non è possibile sapere se l'approccio 1 o l'approccio 2 sono migliori.