Здравствуйте, Sergey, Вы писали:

S>Странно, а мне казалось что OpenSSL весьма грамотно написана. В тех
S>местах, в которые я заглядывал — все довольно понятно было.

терпимо. Хотя тоже однобуквенные переменные к примеру

unsigned long dtls1_output_cert_chain(SSL *s, X509 *x)
    {
    unsigned char *p;
    int n,i;
    unsigned long l= 3 + DTLS1_HM_HEADER_LENGTH;
    BUF_MEM *buf;

потом искать по коду "n" запаришься.

Главное я не понимаю зачем на голимом C, если есть c++, — снижает читаемость.

S>PS: А что плохого в строковых литералах в коде?
неудобно локизовывать.

shrecher пишет:

> S>Странно, а мне казалось что OpenSSL весьма грамотно написана. В тех
> S>местах, в которые я заглядывал — все довольно понятно было.
>
> терпимо. Хотя тоже однобуквенные переменные к примеру
>
> unsigned long dtls1_output_cert_chain(SSL *s, X509 *x)
> {
> unsigned char *p;
> int n,i;
> unsigned long l= 3 + DTLS1_HM_HEADER_LENGTH;
> BUF_MEM *buf;
>
>
>
> потом искать по коду "n" запаришься.
>
> Главное я не понимаю зачем на голимом C, если есть c++, — снижает
> читаемость.

Ну, во-первых, разработчик мог не знать C++. Мог посчитать, что делать
плюсовые внутренности при сишном интерфейсе — не окупится. Мог верить в
мифы на счёт производительности или желал видеть среди пользователей
людей, в такие мифы верящих.


> S>PS: А что плохого в строковых литералах в коде?
> неудобно локизовывать.

А что ж тогда удобно? На мой вкус, так строковый литерал в качестве
идентификатора для локализации куда удобнее, чем скажем какое-то число,
как это частенько (но не всегда) принято при разработке под виндой.
Другое дело, что в OpenSSL сообщения об ошибках вообще не локализованы
(хотя нафиг их переводить — юзер все равно не поймет ни запись
"krb5_cc_get_principal() fails", ни "krb5_cc_get_principal() не
выполнилась").

Здравствуйте, Константин Л., Вы писали:

S>>вывод — если хорошо работает и все нравицца — нефиг смотреть как оно сделано

КЛ>мне туда лазить приходится. и при любой такой необходимости к каждому члену нашей команды приходит депрессия

А я недавно словил пару багов в плагине Миранды SecureIM — он ронял ее при специфических условиях передачи файла. Полез в код. Ужаснулся. Послал разработчику фикс и снес плагин нафиг. Безопасность я ему теперь точно не доверю. Код самой Миранды, кстати, более вылизан, но, все равно, местами очень грязен
И я, аналогично Констатнтину, удивляюсь, как это все работает и боюсь, что многие вещи до сих пор происходят незаметно, потому что сделать ошибку в таком коде очень легко.

Здравствуйте, shrecher, Вы писали:

S>неудобно локизовывать.

Что именно неудобно? Как удобнее?

Здравствуйте, Константин Л., Вы писали:

КЛ>имею дело с thunderbird. резюме — дерьмо. методы на 1500 строк в порядке вещей. свичи на 1500 строк в порядке вещей. написано просто грязно. как это работает я не представляю.

Нужно смотреть на проект в целом. Если
1) продукт качественный
2) поддерживается
3) развивается
то, по большому счету, метод разработки данного продукта имеет право на жизнь. Может быть кому-то методы на 1500 строк удобнее понимать и поддерживать, чем какое-нить ООП-спагетти? Личные предпочтения людей, которые не вовлечены в разработку, как-то вторичны...

Здравствуйте, shrecher, Вы писали:

S>Такое качество кодо достаточно типично для OSS. Похоже код хоть и открытый, поддерживается каким-то одним Гуру. Весь дезайн и идея кода у него в голове. Если попытаться разобраться, что делает bzip2, то крыша едет очень скоро. Так как

S>Разобраться в этой каше, конечно можно, но на это уйдет куча времени и сил. Производительность труда резко падает. Желание работать с таким кодом исчезает очень бысро.

Я бы сказал по другому. Это типично для кода, реализующего сложную взаимосвязанную функциональность. И крыша едет от этой сложности и взяимосвязанности. Да и код зачастую исследовательский: возникает идея и непонятно, принесет она дивиденды или нет. Заранее все педантично оформлять не зватит никакого времени на разработку. Оформлять опосля? Не всегда есть и на это время.

К тому же ты явно недооцениваешь человеческие возможности. Если человек имеет мотивацию, то человек разберется. Причем иногда даже не по исходникам, а по дизасемблированому коду А просто так от сложности предметной области в любом случае не уйти. Нет, я конечно понимаю, что очень хотелось бы, чтобы было так: посмотрел не текст программы архивации, и к концу дня можешь ее улучшать, пробовать свои эвристики. Но так не быват

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

Ниже я попытаюсь высказать несколько слов в защиту по каждому из пунктов. Я не хочу сказать, что я выступаю за всецело такой стиль программирования всегда и во всем. Более того, я не знаком с кодом bzip2. Но каждому перечисленному пункту можно найти оправдания и обоснования. Мне приходилось работать с кодом, который содержал многие перечисленные пункты. Могу сказать, что если код был написан профессионально, то большой проблемы во всем перечисленном не было.

S>1. часто нет описания идеи что каждый модуль делает. Ее можно вытащить из кода, но долго

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

S>2. Минимум комментариев даже для очень нетривиальных методов
S>

s->mtfa[kk] = s->mtfa[s->mtfbase[ii] + jj];

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

S>3. Магические констатны смысл которых может вытекать из общей картины, но не из конкретного метода.
S>

if (uc == 0x17) goto endhdr_2;

Ну будет там стоять STATE_17, будет проще? Не всегда удается придумать адекватное название для состояния. А если придумать, то будет многословно... Например STATE_AFTER_READING_PIECE_SYMBOL_NEXT_SYMBOL_IS_NOT_TAKING. Попробуй их потом объединить в if? Тут возможно даже лучше оставить константы и написать коментарий, что какой magic number обозначает. Но по своему опыту, это не является таким уж необходимым. Начинаешь разбираться и через некоторое время все становится на свои места.

А иногда эти магические константы формируются методом Монте-Карло Например
[quote]
Задача: Надо найти по битборду с занятыми полями битборд с атаками ладьи (слона) с заданного поля.

Решение:
1) Делаем AND битборда занятости с только теми полями, которые влияют на атаки. Для ладьи на любом поле битборд-маска состоит из 12 единиц. Например, для a1 это поля a2...a7, b1...g1 (поля a8 и h1 не входят, т.к. их атакованность ладьёй с a1 не зависит от того, стоит ли на них какая-нибудь фигура)
2) Умножаем маскированный битборд на МАГИЧЕСКОЕ ЧИСЛО ДЛЯ ЛАДЬИ НА А1.
3) Берём от произведения 12 старших разрядов (сдвигом).
4) Получаем 12-разрядное число, которое используем как индекс в предвычисленной таблице атак.

МАГИЧЕСКОЕ ЧИСЛО для каждого поля доски находим методом Монте-Карло, чтобы не было коллизий. Будет два массива, 64 числа для ладьи и 64 для слона. Маски для атак — тоже предвычисленные константы.[/quote]

S>4. Опять макросы, длинные функции по 500 и больше строк

Ну длинные функции, что с того? Предположим, что длина функции не следствие копипаста. А что можно сделать? Например, разбить на более мелкие функции, но поможет ли это? Зато сразу большое количество проблем.
1) Необходимо организовать контекст вычислений
2) Зачастую возникает большое количество флажков, вспомогательных переменных, инициализаций
3) Изменения зачастую приводят к лишним телодвижениям: ввели новую локальную переменную, потом она понадобилась в какой-то из вложенных функций. Надо ее перемещать в контекст вычислений и т. д. и т. п.

Так что при разработке проще держать все вместе одним большим замесом.

S>5. однобуквенные названия переменных (j,i,n,s)

Придумай что получше Зачастую в целях оптимизации приходится хранить и усиленно использовать переменные, которым нет человеческого названия. Нет, я конечно могу объяснить что там хранится, но для этого надо минимум пару предложений. Выделить ключевой слово можно, о тогда возникает проблема конфликта, потому как к этому ключевому слову можно отнести несколько переменных. Нумеровать их?

Здравствуйте, max779, Вы писали:


M>В общем, меня не убедили. А основной косяк этого подхода вот в чем: вот ты пишешь программу и пользуешься этими магическими YIELD и т.д. Потом ты увольняешься, на твое место приходит другой кодер и он не знаком с этим делом... Он конечно познакомится рано или поздно и перепишет весь твой код без этих макросов. И только потому что, чтобы хранить в уме эти магические обновления и переходы надо намного больше усилий... В общем, его мнение о тебе будет таким же как у Lonely Dog об open source.
M>Помните: программы пишутся для человека, а не для машины. Машина разберется в любых goto, а вот у человека голова опухнет...

Вообще-то Coroutine или сопрограммы не являются каким-то тайным знанием, и хороший программист должен если не знать (хороший скорее знать) то хотя бы слышать о них.

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, Lonely Dog, Вы писали:

КЛ>[]

КЛ>имею дело с thunderbird. резюме — дерьмо. методы на 1500 строк в порядке вещей. свичи на 1500 строк в порядке вещей. написано просто грязно. как это работает я не представляю.

Рассматривал исходники iptables, парсер конфигурационных файлов.... в ходе прочтения возникло много вопросов, самым главным был — КАК это все писали и сколько человеко-лет отлаживали...
Старые исходники M$ из экзамплов MSDN тоже, впрочем, изяществом не блещут, но там хотя бы нет функций на десятки экранов кода.

Здравствуйте, Lonely Dog, Вы писали:

LD>Привет!

LD>Приведу несколько примеров:
LD>1. Файл ssh.c
LD>В начале файла есть несколько дефайнов:
LD>

LD>/* Coroutine mechanics for the sillier bits of the code */
LD>#define crBegin1    static int crLine = 0;
LD>#define crBegin2    switch(crLine) { case 0:;
LD>#define crBegin        crBegin1; crBegin2;
LD>#define crFinish(z)    } crLine = 0; return (z)
LD>#define crFinishV    } crLine = 0; return
LD>#define crReturn(z)    \
LD>    do {\
LD>        crLine=__LINE__; return (z); case __LINE__:;\
LD>    } while (0)
LD>#define crReturnV    \
LD>    do {\
LD>        crLine=__LINE__; return; case __LINE__:;\
LD>    } while (0)
LD>#define crStop(z)    do{ crLine = 0; return (z); }while(0)
LD>#define crStopV        do{ crLine = 0; return; }while(0)
LD>#define crWaitUntil(c)    do { crReturn(0); } while (!(c))
LD>#define crWaitUntilV(c)    do { crReturnV; } while (!(c))
LD>

LD>Потом эти дефайны используются в коде следующим образом:

Это достаточно известный паттерн в среде
hardcore С программеров. Про coroutines читаем статью здесь:
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
Там в статье кстати есть ссылка на putty.

Здравствуйте, c-smile, Вы писали:

CS>Это достаточно известный паттерн в среде
CS>hardcore С программеров. Про coroutines читаем статью здесь:
CS>http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
CS>Там в статье кстати есть ссылка на putty.
Автор Putty — это и есть как раз автор этой техники.

Здравствуйте, Phoenics, Вы писали:


P>Детский сад! У нас на работе есть магическая мега-функция оставленная нам "демиургами", её длинна на данный момент ~1800строк, она набита свичами и goto, причём можно ивдеть и такие вещи как:
P>case тра-ля-ля:
P> goto три рубля
P> break;
P>case тра-ля-ля:
P> goto три рубля

P>Как параметр эта функция принимает структуру, объявление которой занимает ~200 строк, что составляет примерно 150 параметров, примерно 1/3 которых некоментированы, и не имеют вменяемых названий...
P>И наконец эта функция вызывается ресурсивно...


Мда, тут обфускатора не надо...

Здравствуйте, Константин Л., Вы писали:

КЛ>имею дело с thunderbird. резюме — дерьмо. методы на 1500 строк в порядке вещей. свичи на 1500 строк в порядке вещей. написано просто грязно. как это работает я не представляю.

В коммерческом коде нашел фунцыю примерно в 200 кб кода Была написана пачкой индокитайцев.

Одно хорошо — в мой код эти индокитайцы не совались, хотя желание было велико.

Что было бы с опенсорсом — и представить не могу, настолько страшно

Здравствуйте, IT, Вы писали:

IT>Качество open-source кода абсолютно ничем не отличается от качества любого другого кода. Как и везде есть код хороший, есть не очень, есть откровенное дерьмо. Не думаю, что кривыми руками за деньги писать получится лучше, чем open-source.

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

В опенсорсе здесь просто анархия, держится на честном слове.

Здравствуйте, Ikemefula, Вы писали:

I>Только в опенсорсе некто недо может влезть насрать где попало. На конторах обычно есть кодинг-стандарты, код-ревью и всякие пакости другие, которые помогают сохранить чистоту кода, хотя бы отчасти.

I>В опенсорсе здесь просто анархия, держится на честном слове.

Это уже не open source, это — trash source. Ни в одном нормальном проекте тебе не дадут гадить просто так. Попробуй, например, нагадить в ядро линукса.

Здравствуйте, Ikemefula, Вы писали:

I>Только в опенсорсе некто недо может влезть насрать где попало. На конторах обычно есть кодинг-стандарты, код-ревью и всякие пакости другие, которые помогают сохранить чистоту кода, хотя бы отчасти.
Ты участвовал в достаточно крупных OpenSource-проектах? Правильно, не участвовал.

Так как в большинстве из них это всё есть.

Ikemefula однажды (12 июня 2008 15:10) писал:

> Только в опенсорсе некто недо может влезть насрать где попало. На конторах обычно есть кодинг-стандарты, код-ревью и всякие пакости другие, которые помогают сохранить чистоту
> кода, хотя бы отчасти.
> В опенсорсе здесь просто анархия, держится на честном слове.
Твои слова держутся на честном слове, извините за каламбур. Не участвовал ты в проектах вестимо...
--
...belive in the matrix...

Здравствуйте, Sheridan, Вы писали:

>> В опенсорсе здесь просто анархия, держится на честном слове.
S>Твои слова держутся на честном слове
...из трех букв, как тот забор :-)

)

)
--
...belive in the matrix...

Здравствуйте, Mystic, Вы писали:


S>>4. Опять макросы, длинные функции по 500 и больше строк

M>Ну длинные функции, что с того? Предположим, что длина функции не следствие копипаста. А что можно сделать?

Не знаю. Если у меня функция не помещается на экране, значит что-то уже не так, значит надо переделывать код.