1. Книга Кернигана и Ритчи великолепна. Если Вы ее еще не прочитали, сделайте это.
2. Помимо нее, есть различные style guides. Вот, например, рекомендации Пайка; а вот правила оформления кода в ядре Linux.
3. Наконец, вокруг много хорошо написанного кода (например, многие опенсорсные библиотеки). Этот код полезно читать и имитировать.

1. Для каждой структуры желательно иметь функцию-фабрику, которая ее выделяет и инициализирует, и функцию-деструктор, которая освобождает ресурсы. Имена функций, работающих со структурой, должны иметь соответствующий префикс.

   qz_t *make_qz(int a, float b);
   void qz_free(qz_t *qz);
   
   int qz_foo(qz_t *qz, qq_t *qq, int n);
   

2. Как только возникает потребность в полиморфном (в ООП смысле) поведении, полезно завести структуру-"поведение" из указателей на функции, и держать ее первым полем у соответствующего типа. При этом указатель на структуру-"потомок" можно спокойно преобразовывать в указатель на структуру-предок (а внутри "методов" — обратно).

   struct qz_ops {
      int (*foo)(qz_t *qz, int a);
      double (*bar)(qz_t *qz, char *s);
   };
   
   struct qz {
     qz_ops *ops;
   }
   
   struct qz_ops qqq_ops = { // стиль объявления C99
     .foo = qqq_foo,
     .bar = qqq_bar
   };
   
   struct qqq {
     qz_t qz;
     int other_field;
   }
   

   и потом

   qz_t *q = make_qqq(); // проинициализирует qqq и установит поле ops
   q->ops->foo(q, 33);
   

   Грубо говоря, эти два правила имитируют C++-классы на коленке, и оказывается, что весь плюсовый синтаксический сахар повышает удобство очень ненамного.
3. Желательно активно пользоваться ограничением видимости. То есть, почти любой тип определяется в хедере просто как

   typedef struct qz qz_t;
   

   в публичных функциях (перечисленных в том же хедере) используется qz_t*, а реальное определение структуры сидит уже в C-шнике. При этом все неэкспортируемые через хедер функции в C-шном файле обозначены как static.
   В результате, в отличие от C++, заголовочные файлы на чистом C вполне можно читать подряд; мусора, касающегося деталей реализации, там нет или почти нет.
   Это правило вступает в противоречие с предыдущим: если мы устраиваем полиморфную структуру, то, по крайней мере, ее член ops должен быть виден извне.

1. Исключений, понятно, нет. Можно либо возвращать ошибку, если функция исходно была бы void, либо передавть указатель на ошибку отдельным аргументом:

   qq_t* qz_make_qq(qz_t *qz, int a1, char *a2, err_t **err);
   

   и потом

   {
     err_t *err = NULL;
     qq_t *qq;
   
     qq = qz_make_qq(qz, 33, "xxx", &err);
     if (err) {
       ...
     }
   }
   

   Это, надо сказать, не слишком красиво. Очень жаль, что в C нет множественных возвращаемых значений.
2. Обрабатывать ошибки можно так:

   int foo() {
     int fd1 = -1;
     int fd2 = -1;
     int fd3 = -1;
   
     fd1 = open(...);
     if (fd1 < 0) goto OUT;
   
     fd2 = open(...);
     if (fd2 < 0) goto OUT;
   
     fd3 = open(...);
     if (fd3 < 0) goto OUT;
   
     ...
   
   OUT:
     close(fd1);
     close(fd2);
     close(fd3);
   }
   

   При этом деструктороподобные функции должны справляться с -1 или NULL. (close и free это умеют, кстати.)

int (*)(int **);
int (*)(int *const *);
int (*)(int const **);
int (* const)(int const *const *);

int foo1(qz_t *qz);

int foo2(qz_t **qzp);

struct qz {
  int i;
  double d;
};

struct qz a, b;

  a = b;

  memmove(&a, &b, sizeof(a));

#ifndef qz_H
#  define qz_H
...
#endif // qz_H

#ifdef qz_H
#  error "qz.h doubly included"
#endif
#define qz_H