Entwurfsprinzipien, Best Practices und Entwurfsmuster für C (oder prozedurale Programmierung im Allgemeinen)? [closed]

Gibt es bekannte Designprinzipien, Best Practices und Designmuster, denen man beim Entwerfen eines C-Projekts folgen kann? Oder nützliche Designprinzipien für prozedurale (imperative) Programmierung im Allgemeinen?

(Ich bin Kind der ‘objektorientierten Generation’ und muss zum ersten Mal ein großes C-Projekt entwerfen)

Information Hiding – wie von Parnas (Software Fundamentals) vertreten.

Sorgfältige Verwaltung von Kopfzeilen und Sichtbarkeit:

• Alles in einer Quelldatei, das vor der Außenwelt verborgen werden kann, sollte; nur die dokumentierte externe Schnittstelle sollte verfügbar gemacht werden.
• Alles, was exponiert ist, wird in einem Header deklariert.
• Dieser Header wird dort verwendet, wo die Funktionalität benötigt wird (und wo sie definiert ist).
• Der Header ist in sich abgeschlossen – wenn Sie ihn brauchen, verwenden Sie ihn, und Sie müssen sich nicht darum kümmern, „welche anderen Header muss ich auch einschließen“, denn der Header stellt sicher, dass er funktioniert, indem er alles enthält, was er benötigt, um ihn zu erstellen Arbeit.

• Der Header ist selbstgeschützt – es spielt also keine Rolle, ob er mehrfach eingebunden wird.

  #ifndef HEADER_H_INCLUDED
  #define HEADER_H_INCLUDED
  ...rest of header contents, including other #include lines if necessary
  #endif /* HEADER_H_INCLUDED */
  

• Entwerfen Sie Sätze von Funktionen, die an „Objekten“ (normalerweise Strukturen) arbeiten – und verwenden Sie diese Funktionen, anstatt im Code, der sie verwendet, in den Innereien der Struktur herumzustöbern. Betrachten Sie es als selbst auferlegte Kapselung.

Meine drei Ratschläge:

• Unit-Tests schreiben. Sie werden Ihnen dabei helfen, sich auf ein Design zu konzentrieren, das zu Ihrem Problem passt, während Sie weitermachen. Viel besser, als sich (ausschließlich) auf vorsätzliches Denken zu verlassen.
• Lassen Sie einen Speicherleckdetektor (es gibt alle Arten von Bibliotheken da draußen) installieren und vom ersten Tag an laufen. Lassen Sie diese Bibliothek alle Lecks ausdrucken, sobald das Programm/die Tests beendet werden. Auf diese Weise können Sie ein Leck sofort nach dem Einführen auffangen, wodurch die Reparatur viel weniger schmerzhaft wird.
• Schreiben Sie OOP-Code in C. Nicht so schwierig. Obwohl es möglich ist, das Überschreiben von Methoden zu emulieren, schlage ich vor, dass Sie mit der Emulation einfacher Objekte beginnen. Selbst dieser einfache Mechanismus kann Ihnen eine große Laufleistung bescheren.

Hier ist ein Beispiel:

typedef struct Vector {
  int size;
  int limit;
  int* ints; 
} Vector;

Vector* Vector_new() {
  Vector* res = (Vector*) malloc(sizeof(Vector));
  res->limit = 10;
  res->size = 0;
  res->ints = (int*) malloc(sizeof(int) * res.limit);

  return res;
}


void Vector_destroy(Vector* v) {
  free(v->ints);
  free(v);
}

void Vector_add(Vector* v, int n) {
  if(v->size == v->limit) {
    v->limit = v->limit * 2 + 10;
    v->ints = realloc(v->ints, v->limit);     
  }

  v->ints[v->size] = n;
  ++v->size;
}

int Vector_get(Vector* v, int index) {
  if(index >= 0 && index < v->size)
    return v->ints[index];

  assert false;
}

Es gibt ein gutes, kostenloses Online-Buch mit dem Titel Objektorientierte Programmierung mit ANSI-Cdas das Thema des Schreibens von objektorientiertem Code in C. A Google-Suche für “objektorientiertes C” liefert auch eine Reihe anderer guter Beispiele und Ressourcen.

Wenn Ihr Projekt sicherheitskritisch ist, MISRA-C ist ein gutes Regelwerk. Es ist hauptsächlich für eingebettetes C gedacht, kann aber auch in anderen Bereichen nützlich sein.

Ich betrachte mich als OO-Programmierer und arbeite viel mit Embedded-C. Der beste Rat, den ich geben kann, insbesondere bei großen Projekten, ist, es nicht zu übertreiben. Das Erstellen eines vollständigen OO-Frameworks auf ANSI C kann sehr verlockend sein, aber es erfordert viel Zeit und Mühe, es richtig hinzubekommen. Je schicker Sie werden, desto mehr Zeit werden Sie mit dem Debuggen Ihres Frameworks verbringen, anstatt an dem zu arbeiten real Projekt. Gehen Sie die Aufgabe mit klarem Kopf und einem guten, soliden Verständnis an YAGNI. Viel Glück!

OOP ist eine Methodik, keine Technologie. Mein erster Ratschlag ist also, dass Sie aufhören, es als prozedurale Programmierung zu betrachten.

Um e.James zu sagen, Sie wollen nicht versuchen, eine objektorientierte Sprache neu zu erstellen oder vorzugeben, dass Sie die Fähigkeiten dazu haben. Sie können immer noch alles richtig machen, indem Sie sich an ein paar einfache Prinzipien halten:

1. Alles Probe fahren.
2. Finden Sie, was variiert, und kapseln Sie es.
3. Design für Schnittstellen.