Средства и методы разработки

Есть чудный документ - Linux Kernel Coding Style ->. Я уже который год его перечитываю, и нахожу в нем что-то новое для себя. И постепенно с ним соглашаюсь. Vit прав - не нужно загружать мозги http://www.llnl.gov/linux/slurm/coding_style.pdf
дополнительной работой. Действительно, в чистом виде, без подстветки, исходники после dogygen читаются не здорово (в случае тщательного документирования, как в приведенных хидерах из WinAVR). Некоторые конструкции dogygen визуально похожи на С, и мозг лихорадочно ищет - а вот эта хрень - она обрамлена каментами или нет? Это функция или просто писанина какая-то? http://img201.imag …/img201/3826/21jm0.png - там самый главный элемент, выделенный колорером - это мыло автора сего хидера. И еще мыло какого-то крендаля, который поведал миру об очень важном атрибуте __ATTR_CONST__. Но обычно в хидер лезут не за мылами их авторов. http://img201.imag …/img201/6624/11kz4.png - не сильно лучше. Лично мне бьет в глаза \ingroup avr_math \ingroup мой мозг вообще отказывается понимать, а вот avr_math - это что-то серьезное! Ибо название напрямую коррелирует с тематикой хидера. И только побегав глазами по строкам, я догоняю, что это камент, и эту часть надо похерить. Так вот, чем больше будут глаза бегать по строкам - тем менее эффективно будут работать мозги. Все подобные каменты надо засеривать, а еще лучше, фолдить одной кнопкой. Вот тогда глаза будут бегать только по тому, что обрабатывает компилятор, э ато уже чуть лучше. Истинная же цель - чтобы глаза не бегали вообще. Чтобы они бегали вслед за ходом программы, чтобы написанное сразу проникало в мозг, и мозг думал только о деле. Идеальный редактор, как и все идеальное, недостижим, но стремиться к нему надо.