Zasady projektowania, najlepsze praktyki i wzorce projektowe dla języka C (lub ogólnie programowania proceduralnego)? [Zamknięte]

Czy są jakieś znane zasady projektowania, najlepsze praktyki i wzorce projektowe, którymi można się kierować podczas projektowania projektu w języku C? Lub ogólnie przydatne zasady projektowania dla programowania proceduralnego (imperatywnego)?

(Jestem dzieckiem pokolenia zorientowanego obiektowo i po raz pierwszy muszę zaprojektować duży projekt w C)

Ukrywanie informacji - za zgodą Parnas ( Podstawy oprogramowania ).

Staranne zarządzanie nagłówkami i widocznością:

• Wszystko w pliku źródłowym, które można ukryć przed światem zewnętrznym, powinno być; powinien być widoczny tylko udokumentowany interfejs zewnętrzny.
• Wszystko, co jest ujawniane, jest zadeklarowane w nagłówku.
• Ten nagłówek jest używany tam, gdzie potrzebna jest funkcjonalność (i gdzie jest zdefiniowana).
• Nagłówek jest samowystarczalny - kiedy go potrzebujesz, używasz go i nie musisz się martwić o to, `` jakie inne nagłówki też muszę uwzględnić '', ponieważ nagłówek zapewnia, że ​​działa, włączając wszystko, czego potrzebuje, aby to zrobić praca.

• Nagłówek jest samozabezpieczający - więc nie ma znaczenia, czy jest dołączany wielokrotnie.

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

• Zaprojektuj zestawy funkcji do pracy na „obiektach” (zwykle strukturach) - i używaj tych funkcji zamiast grzebać w wnętrzach struktury w kodzie, który jej używa. Pomyśl o tym jako o zamknięciu narzuconym przez siebie.

Moje trzy rady:

• Napisz testy jednostkowe. Pomogą Ci skupić się na projekcie, który będzie odpowiadał Twojemu problemowi. O wiele lepsze niż poleganie (wyłącznie) na myśleniu z wyprzedzeniem.
• Zainstaluj i uruchom wykrywacz wycieków pamięci (istnieją różne biblioteki) od pierwszego dnia. Niech ta biblioteka wydrukuje wszystkie wycieki zaraz po zakończeniu programu / testów. Umożliwi to wykrycie wycieku zaraz po jego wprowadzeniu, dzięki czemu jego naprawa będzie znacznie mniej bolesna.
• Napisz kod OOP w C. Nie jest to trudne. Chociaż możliwe jest emulowanie przesłaniania metody, sugeruję zacząć od emulacji prostych obiektów. Nawet ten prosty mechanizm zapewnia duże przebiegi.

Oto przykład:

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

Istnieje dobra, bezpłatna książka online, zatytułowana Programowanie obiektowe z ANSI-C , która porusza temat pisania kodu zorientowanego obiektowo w języku C. Wyszukiwanie w Google słowa „obiektowo zorientowane C” daje również szereg innych dobrych przykłady i zasoby.

Jeśli Twój projekt jest krytyczny dla bezpieczeństwa, MISRA-C to dobry zestaw reguł. Jest przeznaczony głównie dla osadzonego c, ale może być również przydatny w innych obszarach.

Uważam się za programistę OO i dużo pracuję z embedded-C. Najlepsza rada, jaką mogę dać, zwłaszcza w przypadku dużych projektów, to nie przesadzać. Stworzenie kompletnego frameworka obiektowego na bazie ANSI C może być bardzo kuszące, ale jego poprawne wykonanie zajmuje dużo czasu i wysiłku. Im bardziej będziesz bardziej zaawansowany, tym więcej czasu poświęcisz na debugowanie frameworka zamiast pracy nad rzeczywistym projektem. Podejdź do zadania z trzeźwą głową i dobrym, solidnym zrozumieniem YAGNI . Powodzenia!

OOP to metodologia, a nie technologia. Więc moja pierwsza rada to przestań myśleć o tym jako o programowaniu proceduralnym.

Wracając do e.Jamesa, nie chcesz próbować odtworzyć języka zorientowanego obiektowo lub udawać, że masz takie możliwości. Nadal możesz robić wszystkie właściwe rzeczy, trzymając się kilku prostych zasad:

1. Przetestuj wszystko.
2. Dowiedz się, co się różni i zamknij to.
3. Projekt do interfejsów.