Хотелось бы посмотрить на исходники действительно качественно написанного софта (в особенности на C и для встроенных применений). Может у вас бывало такое - читаешь прогу и понимаешь - да, это очень хорошо написанно. Хочется поучится на чужом хорошем примере.

UCOS

Это для каждого слишком индивидуально. Есть конечно "общие" требования и соглашения. Но и они слишком общие.
Но поглядев на исходники и на их алгоритмизацию и концепцию сразу видно когда делал настоящий профессионал, а когда студент. Свой стиль, как собственно и профессионализм вырабатывается годами практи. Вы не сможете вот так просто взять и перенять. Это мой личный взгляд.

Но тем не менее, смотреть хорошо написанный чужой нужно как можно больше. Частенько возникает вопрос, а так ли хорош тот код, с которого вы берете пример?.. UCOS и UC-GUI тоже имеют недочеты, но уже либо совсем незначительные, либо просто концептуальные отличия от вашего собственного стиля (сорри за отсутствие конкретных примеров и аргументов, ибо давно с ними не работал и непомню уже, что мне там не нравилось)
Еще один вывод, который я для себя сделал: Нет предела совершенства к коду относиться на 100%.. не стоит тупо передерать чужие стили, не поняв, "а удобно ли вам самим так.."

P.S. кому-то удобно так:
xxx {
xx
xx
}

кому-то так:
xxx
{
xx
xx
}

Видите ли, сначала придётся определить критерий. Что значит качественно написанный? Тем более для встроенных применений. Есть, к примеру, софт, написанный наглядно, хорошо оформленный, удобный для обучения, переносимости, но не всегда оптимальный по размеру, скорости выполнения, надёжности...

Для этого надо знать откуда стили берутся.
А берутся они как я все больше понимаю от среды программирования.
Даже не от индивидуализма разработчика.
Именно IDE разработчика виновата в том как много он пишет комментов, как расставляет отступы и скобки, как именует и как работает с макросами.

Новичка от профи как раз отличить очень сложно, поскольку корпоративные стандарты и обычная практика тащить куски друг у друга сильно нивелируют различия.

Поэтому хорошо написанный исходник - это исходник раскрывающий всю мощу IDE в которой он писался.





Такие критерии (скорость, размер, надежность) хороши для кусочков размером с пару экранов.
Такие и исходниками то назвать уже трудно по современным меркам.

А серьезные встроенны приложения как на uCLinux, eCOS, VxWorks уже по размеру, скорости, надежности никто не оценивает. Там это просто не реально сравнить.
А остается только для оценки тот самый стиль который как бы и есть косвенный показатель качества.

Хорошо написанному исходнику глубоко по барабану в каком IDE он писался.

Хорошо написанный исходник имеет всего два качества.
1. Оно работает.
2. Через год вы относительно легко вспоминаете за каким чертом тут всего понаписано.

"Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию".
Закон Вейнберга

Вот это я и имел ввиду. Скорость и обем в современных условиях - впонятия вторичные. Надежность - когда нужна, когда нет. Я лично убежден, что читать чужой код нужно - на своих ошибках учитсья дорого.

Задолбали уже этим законом

Э нет, исходник безразличный к IDE будет ужасен и отвратителен, потому что будет просто набит под завязку изощренными макросами и инструкциями условной компиляции.
Такое часто можно видеть в опенсорсах.
Именно потому и тяжело их портировать, что без серьезной чистки там даже спецализированные броузеры исходников не понимают.

Понимать алгоритм исходников программистом не так актуально как возможность свободно его броузить.
Многие вещи в исходниках вообще не надо знать как работают, например алгоритмы сжатия, кодирования в протоколах, внутренние структуры фаловых систем и GUI.
Но их все равно надо отлаживать и для этого они должны быть прозрачны для IDE в которой ведется отладка и для парсера этой IDE.

А работать ни один исходник не будет никогда. Официально признается что каждый килобайт кода в среднем содержит одну ошибку.

Флуда многовато. Из дельных ответов пока только uCOS.

Вы написали ерунду, а все это пропустили мимо. Это не стиль, а формат документа. В том же Code::Blocks можно отформатить как угодно любой исходник. По теме: Вы не найдете хороших программ для МК, написанных на Си, потому что их просто нет. Увы

Один из лично мне понравившихся стилей написания (не как скобочки форматировать, а различные моменты, связанные с обеспечением кроссплатформенности, например) можно посмотреть тут - http://www.ijg.org/files/jpegsrc.v6b.tar.gz

А вообще, тут больше дело вкуса. Мне, например, нравится арбуз, а сосед - свинной хрящик уважает. Так что рекомендую писать так, чтобы сами потом могли разобраться. Мифические "люди, которые придут после меня" могут идти лесом - за то, что они будут ковыряться в Вашем коде, деньги будут получать они, а не Вы, посему Вашего интереса в обеспечении читаемости исходников "для посторонних" нет. Кроме, конечно, отдельных случаев. Но тогда должен быть отдельный тариф

Если есть желание посмотреть как пишут другие люди, я бы порекомендовал почитать эту книгу http://www.rsdn.ru/res/book/prog/codeanalysis.xml
Лично мене она показалась достаточно интересной, почти все рассматриваемые примеры написаны на Си.


А как отличить хорошую программу от плохой ? Плохая будет кусаться и ругаться матом ?

Плохая программа - с недальновидной концепцией.

А что Вы понимаете под программной с "недальновидной концепцией" ? Можно несколько примеров ?

Ну зачем так сразу "Вы написали ерунду"...??
Я написал что думаю, а именно считаю постановку скобок именно частью стиля..
Почитайте Макконела "Совершенный Код".. там много чего интересного на эту тему написано, правда не претендую на принципиальность сего момента до мозга костей.. так, к сведению..


Не знаю как ваш Code::Blocks, никогда в нем не работал..
А вот вам пример уважаемого редактора SLickEdit, что они понимают под словом "style" (в т.ч.)..
Нажмите для просмотра прикрепленного файла

P.S. Хороший стиль - понятие весьма растяжимое, но когда он присутствует, это сразу заметно..

С такими "скобочками" исходники у меня сразу в форматер попадают перед чтением - у меня здоровья не хватить лицезреть такое форматирование . Особенно "радует" выпендреж с табуляциями и парой пробелов в одном флаконе... Такие

изыски тоже расстраивают своей никчемностью.

Я же специально обратил внимание, что не в форматировании дело. Табуляции, скобочки и прочее - это достаточно интимные пристрастия, при необходимости - переформатируется.

а это чудо:

зачем так писать, ведь можно
putc(*p++, out);

while ( p != endfn ) putc(*p, out), p++;
Несколько разношерстных операторов в одной строке - обычно пишут люди которые не знают, что такое пошаговая отладка. Вот сами скажите, как при использовании такого стиля поставить точку останова на putc, а не на while( p != endfn)

ну и ...

тип с маленькой буквы, и не в начале а в конце пишется, что этот тип - указатель. Плохо читаемо, не видно где типы, а где переменные.
Природа переменных не понятна по их имени - т.е. сам указатель, тобиш cinfo в данном случае, никак не показывает, что он указатель, а не экземпляр....
Докучи в исходниках еще и все коментарии с "/*" - клиника.
короче стиль imho очень далек от идеала.

Я бы предпочел хотя бы так:

По крайней мере так легко можно сразу отличить функции от типов, типы от переменных, структуры от указателей на структуры.

...ядро minix3 с комментами на русском. Нельзя сказать, что шедевр, но хороший пример того, сколько и где нужно комментариев чтобы человек прочитавший дополнительно книгу на 600 страниц за вами что-нибудь понял . Есть еще UNIX V6 в комментах на англицом. Тоже шедевр без которого эта ОС вряд ли бы получила такое распространение. Кстати, насколько помню, именно с "зажатия" этой книжицы началась история BSD.

А словом "встроенные применения" не кидайтесь - это сейчас манечка кадровых агенств. Берете материнку VIA, лепите к ней эранчеГ, ставите XP и запитываете все от батареек - и вот оно - "встроенное применение". А еще "встроенное" бывает и на asm, и на FORTH и на FPGA(бу-га-га-га-га )

ммм...нет . Даже не представляю себе такого. src это все-таки не литература. Для меня программирование это посредник меду миром идей и реальной жизнью, оно не может быть самодостаточно.

Кстати о стиле - наверное я бы назвал стилем
1) программирования разбиение задачи на функции(для языка C) - архитектурный стиль,
2) применение языковых конструкций(терпеть не могу "олимпиадного" стиля программирования - это тупо) - синтаксический стиль
3) использование имен переменных, функций и нотаций - на порядок может облегчить "вникание в проект" - стиль оформления.

А уж никак не форматирование...
Но раз уж форматирование таки затронуто попугаю людей и я.

Все исходники форматирую утилитой AStyle стиль GNU. Она отлично работает и рекурсивно - отформатит любой по сложности проект. Правда я извращенец, сознаюсь , определения функций у меня выглядят так



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

Да, выглядит дико . Но... очень хорошо читается даже через годы, и очень быстро позволяет в
"нажитое непосильным трудом" вникать. Но это только "свое". Чужое я так не коверкаю,
разве только то, что уж очень подробно разбираю - т.е. нужны внутренности, а не просто вызов.

Вот прицепились вы все к этой строчке Для любителей пошаговой отладки такого кода два раза нажимаем enter и получаем


Короче, мне нравится. А точка зрения - она как дырка в дупе, у каждого своя

А вот как:
Нажмите для просмотра прикрепленного файла

Добавлю, что code::block просто использует утилитку ASyle которая живет и сама по себе и во множестве других сред и приложений.

любой лоадер, например bios-lt

Я знаю зачем так писать. Вероятно это программа для Кейла, а он кодирует постинкремент очень неэффективно. Но достаточно инкремент вынести в отдельное выражение и код становится в три раза короче. Так что не надо заранее считать всех идиотами.

Чернила для восьмого класса

Это кроссплатформенная библиотека.

Хм, на EDN нас услышали. Секреты технологии bug-killing! т.е. предлагаю новый критерий "хорошести" кода

http://www.embedded.com/216200567?cid=NL_embedded

Не смешно.

Значит разработчики этой библиотеки знали об особенностях Кейла и сделали так, чтобы и он генерил эффективный код - а другие от отделения инкремента хуже код не сделают. И библиотека стала действительно (а не теоретически) кроссплатформенной.

Шутка того-же уровня, что и "программа для Кейла". Так что без обид

Ээээ, простите, какая версия Keil'а и для какого процессора генерирует неэффективный код постинкремента?

Хоть звучит самонадеянно и совсем не убедительно, но, по-моему, самый хорошо написанный софт это тот что вы только что написали.


Доказательства просты.
1) Какой бы сторонний софт не брал, всё равно его под себя лопатишь.
Если уж совсем мало времени, то немного подправляешь. Ну а если больше - то полностью.

2) В своём софте намного проще разобраться чем в чужом.

uVision3 V3.00
C51.exe V7.20
1.


2.