Частично это зависит от того, что вы подразумеваете под «качественным кодом C».
Одним из важных аспектов программы является «делает ли она то, для чего она предназначена»? Это трудно измерить, но важно.
Затем вам нужно узнать, приемлем ли код для компиляторов - использование набора параметров компилятора GCC , предоставленного Cristoph , будет указывать, что код находится в хорошем состоянии. (Несмотря на то, что я бы сказал: -Wno-long-long, это зависит от того, куда ваш код может быть перемещен).
Макет кода важен. Является ли код читаемым как людьми, так и компиляторами? Является ли макет равномерным? Является ли это в одном из стандартных форматов - есть несколько, все с основными указаниями, и если вы используете один из них последовательно, код должен быть в порядке. Это правильно прокомментировано? Это означает, что достаточно комментариев, но не слишком много! В файле должен быть заголовок комментария, указывающий, что в нем - и, возможно, кто его написал, и, возможно, лицензия, под которой он распространяется. На SO было несколько вопросов по этому поводу, включая Professional #include comments . За короткое время написание кода для хорошего стандарта компоновки становится рутиной.
Документация может иметь отношение к делу - как правило, имеет отношение к делу. Как кто-то другой узнает, что код существует, что он делает, как его использовать, когда его использовать, когда его не использовать?
Код должен быть написан с использованием достаточно хороших алгоритмов - он не должен использовать чрезмерные объемы памяти, диска или процессорного времени. Также не должно быть утечки ресурсов. Также нет смысла выжимать последний цикл повышения производительности процессора из процедуры, которая будет использоваться один раз за запуск программы, в течение нескольких миллисекунд, когда она запускается, если только вы не сможете продемонстрировать, что это узкое место производительности для Программа в целом.
Ваутер ван Нифтерик дал превосходный набор указателей тоже.