C progetto che evita i conflitti di denominazione

Question

C progetto che evita i conflitti di denominazione

#1 da (8 voti)
#2 da (4 voti)
#3 da (2 voti)

11

Sto faticando a trovare consigli pragmatici sul mondo reale sulle convenzioni di denominazione delle funzioni per un progetto di libreria C di medie dimensioni. Il mio progetto di libreria è separato in alcuni moduli e sottomoduli con le proprie intestazioni e segue in modo approssimativo uno stile OO (tutte le funzioni accettano una determinata struttura come primo argomento, nessuna globalità, ecc.). Ci piace qualcosa di simile a:

MyLib
  - Foo
    - foo.h
    - foo_internal.h
    - some_foo_action.c
    - another_foo_action.c
    - Baz
      - baz.h
      - some_baz_action.c
  - Bar
    - bar.h
    - bar_internal.h
    - some_bar_action.c

Generalmente le funzioni sono troppo grandi per (per esempio) bastone some_foo_action e another_foo_action in un file di implementazione di foo.c , rendono la maggior parte delle funzioni statiche e chiamiamole un giorno.

Posso occuparmi di spogliare i miei simboli interni ("modulo privato") durante la creazione della libreria per evitare conflitti per i miei utenti con i loro programmi client, ma la domanda è come denominare i simboli nella mia libreria? Finora ho fatto:

struct MyLibFoo;
void MyLibFooSomeAction(MyLibFoo *foo, ...);

struct MyLibBar;
void MyLibBarAnAction(MyLibBar *bar, ...);

// Submodule
struct MyLibFooBaz;
void MyLibFooBazAnotherAction(MyLibFooBaz *baz, ...);

Ma finisco con nomi di simboli lunghi e pazzi (molto più lunghi degli esempi). Se non prefisso i nomi con uno "spazio dei nomi falso", i nomi dei simboli interni dei moduli sono tutti in conflitto.

Nota: non mi interessa il caso Camelcase / Pascal ecc., solo i nomi stessi.

c naming project-structure

posta Dan Halliday 20.06.2013 - 16:21

fonte

3 risposte

4

La solita convenzione per le librerie C consiste nell'usare il nome della libreria come prefisso per nomi utilizzabili esternamente, ad es.

struct MyLibFoo;
void MyLibAFooAction(...);

Per i nomi interni alle librerie che devono ancora essere accessibili in più unità della libreria, non esiste una convenzione stretta, ma vorrei usare un prefisso del nome della libreria e un'indicazione che si tratta di una funzione interna. Ad esempio:

struct MyLibInternalFooBaz;
void MyLibInternalFooBazAction();

Sono d'accordo sul fatto che questo può portare a nomi abbastanza lunghi e difficili da scrivere, ma sfortunatamente questo è il prezzo che dobbiamo pagare per non avere un meccanismo come i namespace C ++. Per ridurre la lunghezza dei nomi, al costo di una certa chiarezza, puoi scegliere di usare le abbreviazioni nei tuoi nomi, ma devi valutare attentamente i vantaggi e gli svantaggi.

risposta data 20.06.2013 - 17:05

fonte

2

Se vuoi evitare lunghi prefissi, puoi abbreviare i nomi delle librerie come quello che Apple fa in iOS e OS X:

NSString è una stringa dalle radici NextStep del sistema operativo
CALayer è un livello di animazione core

risposta data 20.06.2013 - 17:53

fonte

Leggi altre domande sui tag c naming project-structure

Devo capire l'interno di un linguaggio di programmazione? Ho bisogno di un IDE per sviluppare app Android?

score 8 · Accepted Answer

Il prefisso (bene, l'apposizione) è davvero l'unica opzione. Alcuni pattern che vedrai sono <library>_<name> (ad es. OpenGL, runtime ObjC), <module/class>_<name> (ad esempio parti di Linux), <library>_<module/class>_<name> (ad es. GTK +). Il tuo schema è perfettamente ragionevole.

I nomi lunghi non sono necessariamente negativi se sono prevedibili. Il fatto che tu abbia finito con nomi lunghi e funzioni di pazzi troppo grandi per attaccare con le funzioni correlate in un singolo file sorgente solleva preoccupazioni diverse. Avete alcuni esempi più concreti?