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

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

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

Verstecken von Informationen - wie von Parnas ( Software Fundamentals ) unterstützt.

Sorgfältige Verwaltung von Headern und Sichtbarkeit:

• Alles in einer Quelldatei, das vor der Außenwelt verborgen werden kann, sollte sein; Nur die dokumentierte externe Schnittstelle sollte freigelegt werden.
• Alles, was verfügbar gemacht wird, 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 geschlossen - wenn Sie ihn benötigen, verwenden Sie ihn und müssen sich keine Gedanken darüber machen, welche anderen Header ich ebenfalls einschließen muss, da der Header sicherstellt, 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 mehrmals enthalten ist.

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

• Entwerfen Sie Funktionssätze, um an 'Objekten' (normalerweise Strukturen) zu arbeiten - und verwenden Sie diese Funktionen, anstatt die Innereien der Struktur in dem Code zu durchsuchen, der sie verwendet. Betrachten Sie es als selbst auferlegte Kapselung.

Meine drei Ratschläge:

• Schreiben Sie Unit-Tests. Sie helfen Ihnen dabei, ein Design zu finden, das Ihrem Problem im Laufe der Zeit entspricht. Viel besser, als sich (ausschließlich) auf vorher meditiertes Denken zu verlassen.
• Lassen Sie einen Speicherleckdetektor (es gibt alle Arten von Bibliotheken) vom ersten Tag an installieren und ausführen. Lassen Sie diese Bibliothek alle Lecks ausdrucken, sobald das Programm / die Tests beendet werden. Auf diese Weise können Sie ein Leck erkennen, sobald Sie es einführen, wodurch die Fixierung weniger schmerzhaft wird.
• Schreiben Sie OOP-Code in C. Nicht so schwierig. Es ist zwar möglich, das Überschreiben von Methoden zu emulieren, ich empfehle jedoch, mit der Emulation einfacher Objekte zu beginnen. Selbst dieser einfache Mechanismus kann Ihnen eine große Kilometerleistung bringen.

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-C , das das Thema des Schreibens von objektorientiertem Code in C behandelt. Eine Google-Suche nach "objektorientiertem C" liefert auch eine Reihe anderer Vorteile Beispiele und Ressourcen.

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

Ich betrachte mich als OO-Codierer 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, erfordert jedoch viel Zeit und Mühe, um es richtig zu machen. Je ausgefallener Sie werden, desto mehr Zeit verbringen Sie mit dem Debuggen Ihres Frameworks, anstatt am eigentlichen Projekt zu arbeiten. Gehen Sie die Aufgabe mit einem klaren Kopf und einem guten, soliden Verständnis von YAGNI an . Viel Glück!

OOP ist eine Methodik, keine Technologie. Mein erster Rat ist also, es nicht mehr als prozedurale Programmierung zu betrachten.

In Bezug auf e.James möchten Sie nicht versuchen, eine objektorientierte Sprache neu zu erstellen oder so zu tun, als hätten Sie die entsprechenden Funktionen. Sie können immer noch alles richtig machen, indem Sie sich an ein paar einfache Prinzipien halten:

1. Testen Sie alles.
2. Finden Sie, was variiert, und kapseln Sie es.
3. Design zu Schnittstellen.