Proyecto C evitando conflictos de nombres

Estoy luchando por encontrar consejos pragmáticos del mundo real sobre convenciones de nombres de funciones para un proyecto de biblioteca C de tamaño mediano. El proyecto de mi biblioteca está separado en unos pocos módulos y submódulos con sus propios encabezados, y sigue libremente un estilo OO (todas las funciones toman una cierta estructura como primer argumento, no globales, etc.). Se ha puesto algo así como:

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

En general, las funciones son demasiado grandes para (por ejemplo) pegarse some_foo_actiony another_foo_actionen un foo.carchivo de implementación, hacer que la mayoría de las funciones sean estáticas y llamarlo un día.

Puedo tratar de quitar mis símbolos internos ("módulo privado") cuando construyo la biblioteca para evitar conflictos para mis usuarios con sus programas cliente, pero la pregunta es cómo nombrar símbolos en mi biblioteca. Hasta ahora he estado haciendo:

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

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

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

Pero estoy terminando con nombres de símbolos largos y locos (mucho más largos que los ejemplos). Si no prefijo los nombres con un "espacio de nombres falso", los nombres de los símbolos internos de los módulos chocan.

Nota: No me importa el caso Camelcase / Pascal, etc., solo los nombres en sí.

Prefijar (bueno, fijar) es realmente la única opción. Algunos patrones que verá son <library>_<name>(por ejemplo, OpenGL, ObjC runtime), <module/class>_<name>(por ejemplo, partes de Linux), <library>_<module/class>_<name>(por ejemplo, GTK +). Tu esquema es perfectamente razonable.

Los nombres largos no son necesariamente malos si son predecibles. El hecho de que esté terminando con nombres largos y funciones locos que son demasiado grandes para seguir con funciones relacionadas en un solo archivo fuente plantea diferentes preocupaciones. ¿Tienes algunos ejemplos más concretos?

La convención habitual para las bibliotecas C es usar el nombre de la biblioteca como prefijo para los nombres que se pueden usar externamente, p. Ej.

struct MyLibFoo;
void MyLibAFooAction(...);

Para los nombres internos de la biblioteca que aún deben estar accesibles en varias unidades de la biblioteca, no existe una convención estricta, pero usaría un prefijo del nombre de la biblioteca y una indicación de que es una función interna. Por ejemplo:

struct MyLibInternalFooBaz;
void MyLibInternalFooBazAction();

Estoy de acuerdo en que esto puede conducir a nombres que son bastante largos y difíciles de escribir, pero desafortunadamente ese es el precio que tenemos que pagar por no tener un mecanismo como los espacios de nombres C ++. Para reducir la longitud de los nombres, a costa de cierta claridad, puede optar por usar abreviaturas en sus nombres, pero debe sopesar cuidadosamente las ventajas y desventajas.

Si desea evitar los prefijos largos, puede abreviar los nombres de las bibliotecas como lo que Apple hace en iOS y OS X:

• NSString es una cadena de las raíces NextStep del sistema operativo
• CALayer es una capa de animación principal

¿Qué pasa con tener una variable de estructura global precargada con punteros de función?

lib.h

#pragma once

typedef struct
{
    void (*doFoo)(int x);
    const char *(*doBar)(void *p);
} YourApi;

extern const YourApi yourApi;

lib.c:

#include "lib.h"

#include <stdio.h>

static void doFoo(int x)
{
    printf("Doing foo %d\n", x);
}

static const char *doBar(void *p)
{
    printf("Doing bar: %p\n", p);
    return "Hello";
}

const YourApi yourApi = {
    doFoo,
    doBar};

Aprovechar:

#include "lib.h"

int main()
{
    yourApi.doFoo(42);
    yourApi.doBar("asd");
}

La palabra clave estática limita el alcance a la unidad de traducción para que no choque con otros.

El usuario puede acortarlo usando un puntero como YourApi *ya = &yourApi, luego usando ya->doFoo(...).

También proporciona una buena manera de burlarse de su biblioteca para realizar pruebas.