Про чтение чужого кода уже пошучено много шуток, нарисован вагон картинок и выдернута куча волос. Да что там чужого... Иногда можно и от своего кода изрядно вспотеть, если он распух до определённого количества строк или с момента последнего обращения к нему прошло много времени. Со временем и опытом к программисту (обычно) приходит умение оформлять код таким образом, что и его жизнь упрощается, и на форумах охотнее помогают, и коллеги реже угрожают расправой. Но зачем ограничиваться лишь собственным опытом, когда есть чужой? Например, сократить "путь к успеху" можно с помощью книги Аллена Голуба (Allen Holub) "Правила программирования на Си и Си++".

Книга давно стала классикой. Оригинальное название - "Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming". С ним лучше видно, что чувство юмора у автора имеется, что есть признак того, что чтение должно пойти легко :) В книге даётся большое количество рекомендаций по оформлению кода таким образом, чтобы его было проще сопровождать - как лучше группировать код в функции, как правильно писать комментарии, как выравнивать отступы, как давать имена переменным, каких подвохов ожидать от препроцессора и т.д.. И всё это - с аргументами и примерами. Также есть немного советов на тему разработки ПО в целом, причём часть из них, несмотря на название книги, нацелена на всех программистов, а не только на сишников. Всего этих советов 161 (!!), и собраны они в 8 глав. Для чуть более ясного представления о содержимом книги можно ознакомиться со списком этих правил на сайте автора (на английском, без комментариев).

Чтобы далеко не бегать, рассмотрим несколько правил прямо здесь. Например, правило 30: "Используйте аккуратные столбцы везде, где можно " (Use neat columns as much as possible). Согласно этому правилу, код желательно оформлять так, чтобы комментарии выделялись геометрически, т.е. они должны быть выстроены в линейку. Например, как на иллюстрации ниже, хотя сам автор книги идёт дальше и кроме комментариев при объявлении переменных отдельно выравнивает типы переменных и их имена, а так же знаки равенства в операциях присваивания. Ну, если имена переменных и названия типов в соседних строках имеют слишком разную длину (как int и unsigned long long), то результат такого тотального выравнивания может выглядеть диковато. В любом случае, это вам решать, какое количество "столбцов" является удобным :) Автор всё равно не настаивает на своей 100% правоте.

Правило 44 гласит: " Имена должны быть обычными словами английского языка, описывающими то, что делает функция, аргумент или переменная" (Names should be common English words, descriptive of what the function, argument, or variable does). Автор, сам будучи англоговорящим, имел в виду, что не нужно злоупотреблять абревиатурами или искажёнными версиями слов, поскольку они ухудшают читаемость кода. В качестве пример он приводил название функции creat(), которую логичнее было бы назвать create(). Но поскольку книга является переводом, в ней не затронут один интересный момент, характерный для наших краёв - транслит. Так вот, по распространённому мнению, правило продолжает работать и у нас, а транслит лучше не использовать. Во-первых, названия переменных и функций станут длиннее, чем на чистом английском, а во-вторых, транслит у всех разных и в команде с ним работать не удобно (да и одному тоже можно запутаться).

Что касается конретно языка C и непосредственно программирования на нём (а не написания самодокументируемого кода), то ему посвящены скромные правила 85-89. В правиле 85 (Подавляйте демонов сложности) приводится интересная таблица с распространёнными стилистическими ошибками, связанными с выполнением лишних действий, а так же примеры исправления этих ошибок. Есть смысл просмотреть эту таблицу - вдруг в ней найдётся пара привычек, оставшихся с незапамятных времён?

В общем, книга полезная. Конечно, с одного прочтения знатоком элегантного программирования не стать, но это уже будет шаг в нужную сторону. Главное - не забывать следовать правилу №20, а то на остальные 160 здоровья не хватит ;)