Привдите пример хорошо написанного встроенного софта Опции

[BSVi]

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

[Methane]

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

UCOS

[demiurg_spb]

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

[Legotron]

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

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

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

[Herz]

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

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

[AlexandrY]

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

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

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

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

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

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

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

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

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

[DpInRock]

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

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

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

[Anato]

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

[BSVi]

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

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

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

[777777]

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

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

[AlexandrY]

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

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

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

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

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

[BSVi]

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

[_Pasha]

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

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

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

[Rst7]

Хотелось бы посмотрить на исходники действительно качественно написанного софта

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

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

[kurtis]

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

Вы не найдете хороших программ для МК, написанных на Си, потому что их просто нет.

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

[_Pasha]

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

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

[kurtis]

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

[Legotron]

Вы написали ерунду, а все это пропустили мимо. Это не стиль, а формат документа.

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

В том же Code::Blocks можно отформатить как угодно любой исходник.

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


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

[zltigo]

Один из лично мне понравившихся стилей написания (не как скобочки форматировать,

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

Код

    
while ( p != endfn ) putc(*p, out), p++;

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

[Rst7]

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

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

[defunct]

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

а это чудо:

Код

putc(*p, out), p++;

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

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

ну и ...

Код

GLOBAL(void)
jpeg_start_compress (j_compress_ptr cinfo, boolean write_all_tables)
{

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

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

Код

void JPEG_StartCompress( PJPEG_COMPRESS pCompressInfo, BOOL write_all_tables)
{

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

[DRUID3]

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

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

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

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

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

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

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

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

Код

/*============================================================================*/
/*
идея алгоритма помещенного в функцию в очень развернутом виде. Может кому-то
легко потом "наглаз парсить" исходник кем-то когда-то написанного адаптивного
фильтра, например, то мне даже свой бывает тяжело понять. А я не верю, что можно
использовать исходник не понимая идею туда помещенную. Имеется ввиду другим
программистом, а не для того чтобы собрать приложение если нет rpm, разумеется.
*/
fn_foo                                                        /* идея кратко, идет потом в .h */
(
type arg,                                                        /* это аргумент отвечающий за "a" */
type brg,                                                        /* это аргумент отвечающий за "b" */
type crg,                                                        /* это аргумент отвечающий за "c" */
...
)
/*----------------------------------------------------------------------------*/
{
  bla-bla-bla;                                                           /* 1 */
/*----------------------------------------------------------------------------*/
  blo-blo-blo;                                                           /* 2 */
}
/* 1 - ая сноска  */
/* 2 - ая сноска */

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

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

[Rst7]

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

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

Код

while ( p != endfn )
putc(*p, out),
p++;

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

[MrYuran]

Не знаю как ваш Code::Blocks, никогда в нем не работал..

А вот как:

[DRUID3]

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

[dch]

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

[777777]

а это чудо:

Код

putc(*p, out), p++;

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

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

[Rst7]

Вероятно это программа для Кейла

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

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

[AlexandrY]

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

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

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

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

[777777]

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

Не смешно.

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

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

[Rst7]

Не смешно.

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

[defunct]

Вероятно это программа для Кейла, а он кодирует постинкремент очень неэффективно.

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

[SasaVitebsk]

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


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

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

[777777]

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

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

Код

603   1              while(*pstr != 0)
604   1                      {
605   2                      if(!PrintChar(*pstr++))
606   2                              return 0;
607   2                      }

Код

0008         ?C0115:
                                          ; SOURCE LINE # 603
0008 8D82              MOV     DPL,R5
000A 8C83              MOV     DPH,R4
000C E4                CLR     A
000D 93                MOVC    A,@A+DPTR
000E 6011              JZ      ?C0116
                                          ; SOURCE LINE # 604
                                          ; SOURCE LINE # 605
0010 0D                INC     R5
0011 ED                MOV     A,R5
0012 7001              JNZ     ?C0137
0014 0C                INC     R4
0015         ?C0137:
0015 14                DEC     A
0016 F582              MOV     DPL,A
0018 E4                CLR     A
0019 93                MOVC    A,@A+DPTR
001A FF                MOV     R7,A
001B 120000      R     LCALL   _PrintChar
001E 40E8              JC      ?C0115
                                          ; SOURCE LINE # 606
0020 22                RET    
                                          ; SOURCE LINE # 607
0021         ?C0116:

2.

Код

603   1              while(*pstr != 0)
604   1                      {
605   2                      if(!PrintChar(*pstr))
606   2                              return 0;
607   2                      ++pstr;
608   2                      }

Код

0008         ?C0115:
                                          ; SOURCE LINE # 603
0008 8D82              MOV     DPL,R5
000A 8C83              MOV     DPH,R4
000C E4                CLR     A
000D 93                MOVC    A,@A+DPTR
000E FF                MOV     R7,A
000F 600D              JZ      ?C0116
                                          ; SOURCE LINE # 604
                                          ; SOURCE LINE # 605
0011 120000      R     LCALL   _PrintChar
0014 4001              JC      ?C0117
                                          ; SOURCE LINE # 606
0016 22                RET    
0017         ?C0117:
                                          ; SOURCE LINE # 607
0017 0D                INC     R5
0018 BD0001            CJNE    R5,#00H,?C0137
001B 0C                INC     R4
001C         ?C0137:
                                          ; SOURCE LINE # 608
001C 80EA              SJMP    ?C0115