Projekt C unikający konfliktów nazw

Z trudem znajduję pragmatyczne porady w świecie rzeczywistym dotyczące konwencji nazewnictwa funkcji dla średniej wielkości projektu biblioteki C. Mój projekt biblioteczny jest podzielony na kilka modułów i podmodułów z własnymi nagłówkami i luźno podąża za stylem OO (wszystkie funkcje przyjmują pewną strukturę jako pierwszy argument, brak globałów itp.). Położyliśmy nasze coś takiego:

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

Zasadniczo funkcje są o wiele za duże, aby (na przykład) trzymać some_foo_actioni another_foo_actionw jednym foo.cpliku implementacji ustawić większość funkcji w trybie statycznym i nazwać to dniem.

Mogę poradzić sobie z usuwaniem symboli wewnętrznych („modułu prywatnego”) podczas tworzenia biblioteki, aby uniknąć konfliktów dla moich użytkowników z ich programami klienckimi, ale pytanie brzmi: jak nazwać symbole w mojej bibliotece? Do tej pory robiłem:

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

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

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

Ale kończę na szalonych długich nazwach symboli (znacznie dłuższych niż w przykładach). Jeśli nie poprzedzę tych nazw „fałszywą przestrzenią nazw”, nazwy symboli wewnętrznych modułów będą się kolidować.

Uwaga: nie obchodzi mnie skrzynka na camelcase / Pascal itp., Same nazwy.

Prefiksowanie (cóż, afiksowanie) jest naprawdę jedyną opcją. Niektóre wzorce, które zobaczysz to <library>_<name>(np. Środowisko uruchomieniowe OpenGL, ObjC), <module/class>_<name>(np. Części systemu Linux), <library>_<module/class>_<name>(np. GTK +). Twój plan jest całkowicie uzasadniony.

Długie nazwy niekoniecznie są złe, jeśli można je przewidzieć. Fakt, że kończysz na szalonych długich nazwach i funkcjach, które są zbyt duże, aby trzymać się powiązanych funkcji w jednym pliku źródłowym, budzi różne obawy. Czy masz jakieś konkretne przykłady?

Zwykłą konwencją dla bibliotek C jest użycie nazwy biblioteki jako prefiksu dla nazw używanych zewnętrznie, np

struct MyLibFoo;
void MyLibAFooAction(...);

W przypadku wewnętrznych nazw bibliotek, które muszą być nadal dostępne w wielu jednostkach biblioteki, nie ma ścisłej konwencji, ale użyłbym prefiksu nazwy biblioteki i wskazania, że ​​jest to funkcja wewnętrzna. Na przykład:

struct MyLibInternalFooBaz;
void MyLibInternalFooBazAction();

Zgadzam się, że może to prowadzić do dość długich i trudnych do wpisania nazw, ale niestety taką cenę musimy zapłacić za brak mechanizmu takiego jak przestrzenie nazw C ++. Aby skrócić długość nazwisk, kosztem pewnej przejrzystości, możesz zdecydować się na użycie skrótów w swoich nazwach, ale musisz dokładnie rozważyć zalety i wady.

Jeśli chcesz uniknąć długich prefiksów, możesz skrócić nazwy bibliotek, takie jak to, co robi Apple w iOS i OS X:

• NSString jest łańcuchem z korzeni systemu operacyjnego NextStep
• CALayer jest warstwą Core Animation

A co z globalną zmienną struktury wypełnioną wskaźnikami funkcji?

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};

Uprząż:

#include "lib.h"

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

Statyczne słowo kluczowe ogranicza zakres do jednostki tłumaczącej, więc nie będzie kolidować z innymi.

Użytkownik może następnie skrócić go za pomocą wskaźnika podobnego do YourApi *ya = &yourApi, a następnie za pomocą ya->doFoo(...).

Zapewnia również dobry sposób na wyśmiewanie biblioteki do testowania.