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

F>Здравствуйте, мыщъх, Вы писали:

М>>написанных на смеси питона с руби.
F>а как случилась подобная содомия?. и за какие части что отвечает?.
когда меня брали на работу, я знал только си и писал на нем реал-таймовый код (и тут си вне конкуренции). позже меня подписали на data mining в off-line режиме, где разница между 10 ms и 10 sec несущественна, и начальство стало меня пинать учить руби, на котором мои коллеги уже написали кучу кода, вызывающего мои сишные модули. почитав пару книжек на выходных по руби и питону, я обнаружил, что питон настолько прост, что я на нем уже могу программировать, пускай и в сишном стиле. руби тоже несложен, но как-то у нас с ним не слюбилось и потому в проекте стало на один язык больше. конечно, это минус, т.к. генеральному архитектору добавилось головной боли (т.к. теперь еще и пион за собой таскать, да еще и нужной версии), но с другой стороны питон -- компилируемый, а руководство озабоченно "у нас сопрут интеллектуальную собственность, представленную в виде скриптов". а компилятор питона генерирует такую жуткую лапшу, что хрен ее декомпилируешь обратно и потому вместо того, чтобы меня пинками загонять на руби, руководство предпочло плюс еще один язык.

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

короче, вот такой мясной рулет. но он работает и это главное.

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

P>>>Нет, много хорошего кода, и в опенсорсе, и в МС, и в другом. Только мне ваш вопрос, напомнил о моей "проблемме" — все время рефакторю код, и не потому что он плох, он работает, и за год, ни одного бага, но рефакторю из любви к красивому, и тут нать, баги ... Как от этой привычки избавиться?
N>>Ничего не понял. Расшифруйте.
P>Вот пишите вы код. Часто в дедлайне, поэтому — архитектурно — он не красив. Потом вы его поддерживаете... Потом — есть у вас время — начинаете в нем красоту наводить (и архитектурно и локально), и багов после этого больше, чем в первоначально было...

Почему это багов больше? При правильном подходе этот процесс не создаёт новые баги.

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

IT>>Да ладно! Количество багов, уходящих в продакшин у вас тоже формализовано?
T>У нас баги в основном лезут из-за недокументированных особенностей сторонних компонент. В ядре Windows их не перечесть

А зачем вы лазиете в ядро Windows?

T>Так а откуда баги то берутся? Не дизайновые, а именно тупые ошибки кодирования. Элементарные правила как раз и нужны чтобы уменьшить вероятность их появления. То что облась эта хорошо формализуемая, надеюсь нет сомнений?

Есть.

T>Умные компиляторы выдают варнинги на любой чих, есть отдельные анализаторы для разных языков и платформ. Все в конечном итоге упирается в человеческий фактор, аккуратность в соблюдении набора известных правил. Т.е. если все написано так что баг там невозможен, то его и не будет

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

T>Просвети же наконец, что ты то понимаешь под _качеством кода_?

Я не знаю Знал бы — не спрашивал. Могу только предположить, что к разному коду могут предъявляться абсолютно разные требования, в том числе и к его качеству. А по сему разговор, который вы здесь ведёте мне странен и непонятен.

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

LVV>Кто может привести примеры прекрасного качества кода?

Можно-с. Только код привести не получится. Во многих случаях большой он для rsdn-на. Почему? А потому что он не из книжек, а из жизни.

Было дело, один коллега написал преобразование текста из одного формата в другой на XSLT. Я ему сразу сказал, что он сошел с ума. Но этот код просуществовал долго, пока мне с ним не пришлось работать. Тогда он был переписан за один день на перле. Самое смешное, что xslt код был достаточно длинный. Но код на перле получился короткий, буквально в 1.5 экрана. Поэтому я просто послал этот код коллеге в назидание по почте (а остальных добавил в CC, чтобы они прикололись).

Было дело, один коллега недопонял модель MVC и написал код на C++, где между model, view и controller передавались сообщения через тип VARIANT (запаковывались в VARIANT, а потом распаковывались из VARIANT в огромных switch-ах, — да, коллега был немного долбанутым, извените за выражение). Другие коллеги как-то мирились с этим кодом и, вроде, даже не жаловались. Только продуктивность почему-то была небольшая. И я понял почему, когда мне пришлось добавить пару сообщений в этот код. Я буквально на каждое сообщение тратил дня два (сначала куча нетривиального кода, а потом мучительная отладка). Мне хотелось обложить коллегу матом, но к сожалению, он бы не оценил, так как он не умел говорить по-русски. Пришлось потратить еще два дня, выкинуть весь его код и переписать его на@#$. Он после этого все-таки сказал мне спасибо, и я подумал, ладно живи, bastard.

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

LVV>Кто может привести примеры прекрасного качества кода?
LVV>Из жизни, а не из книжек.

Не знаю насчет прекрасности, но

Например есть такая схема HTTP: http://webmachine.basho.com/diagram.html
И вот, как с ней работает webmachine: https://github.com/basho/webmachine/blob/master/src/webmachine_decision_core.erl

Обращаю внимание:

%% "Service Available"
decision(v3b13) ->

%% "Known method?"
decision(v3b12) ->

%% "URI too long?"
decision(v3b11) ->

И т.п. v3 — это версия схемы. b13, b12 и т.п. — соответствующее место на схеме. В итоге код получается достаточно поянтынм и документированым.

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


LVV>>Кто может привести примеры прекрасного качества кода?
LVV>>Из жизни, а не из книжек.

M>Не знаю насчет прекрасности, но

M>Например есть такая схема HTTP: http://webmachine.basho.com/diagram.html
M>И вот, как с ней работает webmachine: https://github.com/basho/webmachine/blob/master/src/webmachine_decision_core.erl

M>И т.п. v3 — это версия схемы. b13, b12 и т.п. — соответствующее место на схеме. В итоге код получается достаточно поянтынм и документированым.

Взгляд со стороны.
Сначала посмотрел код. Ничего не понятно: туча decision(v3*) которые не понятно что делают. Что будет если циферкой ошибешься и вместо 4 напишешь 5. Особенно вот это v3l13 — это "V три тысячи сто тринадцать" или "V тридцать один L три" или V три L тринадцать?
Посмотрел диаграмму — какие-то знакомые кодовые буковки и циферки, где то я их видел, сама диаграмма достаточно понятна, а код еще под вопросом. А после того как я прочитал что код реализует эту диаграмму — теперь все понятно, но v3l13 не одобряю, хотя если проводить аналогии с диаграммой то можно сделать вывод о формате кодирования состояний.
Выводы: код — "плохой", диаграмма — "хорошая", код вместе с диаграммой — достаточно хороший. То есть в данном случае "качество" диктуется документацией. Про качество продукта (программного средства) ничего не известно, гулить не хочется.

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

I>>Как меряли ? Разбор полетов проводили ? Как тестировали ? Регрессионные тесты были ?

T>Я же вроде ясно написал — недокументированные особенности. Т.е. формально наш код правильный.

Ого, это сильно — писать без багов

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

T>Так делай все так чтоб контроль не терялся. Соблюдай правила языка, придерживайся определенного стиля. Не делай тупых ошибок. И все будет хорошо

Я уже объяснил, почему это невозможно.

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

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

IT>>>Да ладно! Количество багов, уходящих в продакшин у вас тоже формализовано?
T>>У нас баги в основном лезут из-за недокументированных особенностей сторонних компонент. В ядре Windows их не перечесть

IT>А зачем вы лазиете в ядро Windows?

Работа такая.

T>>Так а откуда баги то берутся? Не дизайновые, а именно тупые ошибки кодирования. Элементарные правила как раз и нужны чтобы уменьшить вероятность их появления. То что облась эта хорошо формализуемая, надеюсь нет сомнений?

IT>Есть.

T>>Умные компиляторы выдают варнинги на любой чих, есть отдельные анализаторы для разных языков и платформ. Все в конечном итоге упирается в человеческий фактор, аккуратность в соблюдении набора известных правил. Т.е. если все написано так что баг там невозможен, то его и не будет

IT>Я же говорю, где-то вы там у себя серебрянную пульку прикопали и не сознаётесь.

T>>Просвети же наконец, что ты то понимаешь под _качеством кода_?

IT>Я не знаю Знал бы — не спрашивал. Могу только предположить, что к разному коду могут предъявляться абсолютно разные требования, в том числе и к его качеству. А по сему разговор, который вы здесь ведёте мне странен и непонятен.

— Дважды два = четыре.
— Не, ну это эмоции Капитана Очевидность. Я предполагаю что это таки предел функции x в квадрате, при x стремящемся к 2. Пределы можно считать по разному, да и вообще там целая теория, странная и непонятная.

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

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

I>>>Как меряли ? Разбор полетов проводили ? Как тестировали ? Регрессионные тесты были ?

T>>Я же вроде ясно написал — недокументированные особенности. Т.е. формально наш код правильный.

I>Ого, это сильно — писать без багов

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

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

T>>Так делай все так чтоб контроль не терялся. Соблюдай правила языка, придерживайся определенного стиля. Не делай тупых ошибок. И все будет хорошо

I>Я уже объяснил, почему это невозможно.

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

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

I>>Ого, это сильно — писать без багов

T>А что тут особенного? Сишный код, написанный четко по документации. Выдает на выходе ровно то что должно выходить. Баги есть в основном логические, те что выше. А формальную правильность можно даже доказать если сильно нужно. Теория неподвижной точки тут применима, но очень объемное доказательство выйдет Вы в курсе про эту возможность, или снова дважды два не четыре?

Я никогда не поверю, что сишные программисты никогда не ошибаются с указателями

I>>Я уже объяснил, почему это невозможно.

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

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

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

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

I>>>Ого, это сильно — писать без багов

T>>А что тут особенного? Сишный код, написанный четко по документации. Выдает на выходе ровно то что должно выходить. Баги есть в основном логические, те что выше. А формальную правильность можно даже доказать если сильно нужно. Теория неподвижной точки тут применима, но очень объемное доказательство выйдет Вы в курсе про эту возможность, или снова дважды два не четыре?

I>Я никогда не поверю, что сишные программисты никогда не ошибаются с указателями

Дотнетчик детектед

I>>>Я уже объяснил, почему это невозможно.

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

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

Мне поздно определяться. Я слишком стар и богат для этого (c)

Возвращаясь к тому что выше, я как раз и писал о минимальных требованиях чтобы достичь наименьшей вероятности проблем, т.е. "глупых" ошибок.

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

I>>Я никогда не поверю, что сишные программисты никогда не ошибаются с указателями

T>Дотнетчик детектед

Периодически мне приходится фиксить баги в указателях за сищниками. Так что у моего скептицизма есть серьёзное основание.

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

T>Мне поздно определяться. Я слишком стар и богат для этого (c)

T>Возвращаясь к тому что выше, я как раз и писал о минимальных требованиях чтобы достичь наименьшей вероятности проблем, т.е. "глупых" ошибок.

Похоже у тебя таки есть серебряная пулька. Почему ты сидишь на этом форуме а не возглавляешь контору вроде Микрософт или Google ?

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

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

I>>>Я никогда не поверю, что сишные программисты никогда не ошибаются с указателями

T>>Дотнетчик детектед

I>Периодически мне приходится фиксить баги в указателях за сищниками. Так что у моего скептицизма есть серьёзное основание.

Ведь фиксишь видимо успешно. Значит таки можно все делать без ошибок, если постараться.

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

T>>Мне поздно определяться. Я слишком стар и богат для этого (c)

T>>Возвращаясь к тому что выше, я как раз и писал о минимальных требованиях чтобы достичь наименьшей вероятности проблем, т.е. "глупых" ошибок.

I>Похоже у тебя таки есть серебряная пулька. Почему ты сидишь на этом форуме а не возглавляешь контору вроде Микрософт или Google ?

Я в отпуске, шалю Кстати чтобы возглавлять крупную контору желательно вообще никогда не иметь дело с кодированием и прочими грязными делами. Прокачивать интуицию, здравый смысл и красноречие

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

T>А что тут особенного? Сишный код, написанный четко по документации. Выдает на выходе ровно то что должно выходить. Баги есть в основном логические, те что выше. А формальную правильность можно даже доказать если сильно нужно. Теория неподвижной точки тут применима, но очень объемное доказательство выйдет Вы в курсе про эту возможность, или снова дважды два не четыре?

Можно вопрос? Спасибо! Если у вас всё так формально определено ещё до написания кода, то зачем вам вообще программисты? Мы в таких случаях просто тупо генерируем код и всё. Про метапрограммирование слышал? Вот как раз оно очень хорошо заменяет обезъянок. Рекомендую.

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

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

T>>А что тут особенного? Сишный код, написанный четко по документации. Выдает на выходе ровно то что должно выходить. Баги есть в основном логические, те что выше. А формальную правильность можно даже доказать если сильно нужно. Теория неподвижной точки тут применима, но очень объемное доказательство выйдет Вы в курсе про эту возможность, или снова дважды два не четыре?

IT>Можно вопрос? Спасибо! Если у вас всё так формально определено ещё до написания кода, то зачем вам вообще программисты? Мы в таких случаях просто тупо генерируем код и всё. Про метапрограммирование слышал? Вот как раз оно очень хорошо заменяет обезъянок. Рекомендую.

Генераторы кода на одноразовые задачи не пишут. Не та область чтоб тупо генерировать код. Без 2-3 лет подготовки разработчик даже доки к WDK понять как следует не сможет, ничего себе "обезьянки".

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

IT>>Можно вопрос? Спасибо! Если у вас всё так формально определено ещё до написания кода, то зачем вам вообще программисты? Мы в таких случаях просто тупо генерируем код и всё. Про метапрограммирование слышал? Вот как раз оно очень хорошо заменяет обезъянок. Рекомендую.

T>Генераторы кода на одноразовые задачи не пишут. Не та область чтоб тупо генерировать код. Без 2-3 лет подготовки разработчик даже доки к WDK понять как следует не сможет, ничего себе "обезьянки".

Доки понять не может, но пишет почему то без багов ?

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

LVV>>Кто может привести примеры прекрасного качества кода?
DO>Прекрасный код это код, который пишу я в текущий момент, все остальное — отстой, включая мой код, который я писал вчера .

идеально!

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

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

IT>>Единообразие это хорошо, если в меру. Но говорит это лишь о единообразности, а не о качестве

T>контр-пример типичные признаки говнокода:
T>- В проекте используется куча разных нотаций.

Это не признак говнокода. Немного усложняет чтение, но говнокод — несколько иное.


T>- Названия переменных, функций, классов ни о чем не говорят

Согласен.


T>- В каждом подпроекте своя реализация примитивов всяких строк, контейнеров.

Довольно странно. Кто позволил программерам заниматься велосипедостроением? Однако учитывая множество всяких фрэймворком и примитивов созданных для C++...
Однако, это всё равно не говнокод.


T>- Повсеместный копипаст с минимальными заплатками.

Согласен.


T>- Изменение/добавление фичи требует перелопачивания кучи файлов.

Это косвенный признак, который сам по себе не говорит ни о чём.


T>- Проект делается под узкие текущие требования. При любом изменении в них проще переделать все...

Это вообще отдельная, очень хорошая для обсуждения тема. Вот только имеет ли это отношение к качеству кода...!?


T>- перекроить тонны спагетти.

Спагетти — да, согласен.

Здравствуйте, мыщъх, Вы писали:

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

LVV>>Кто может привести примеры прекрасного качества кода?
М>курим ГОСТ 28195–99. кстати, международный. а еще есть гост на качество колбасы. все гостировано.

Скачал, почитал.
Это не мануал по определению качества кода. Множество строк в этом документе спорно, и требует "разжовывания"...

А вообще нужно читать.
"Complete Code" Макконела.

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

Ф>Здравствуйте, мыщъх, Вы писали:

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

LVV>>>Кто может привести примеры прекрасного качества кода?
М>>курим ГОСТ 28195–99. кстати, международный. а еще есть гост на качество колбасы. все гостировано.

Ф>Скачал, почитал.
Ф>Это не мануал по определению качества кода. Множество строк в этом документе спорно, и требует "разжовывания"...
но это гост. если не кладезь мудрости, то мудрость кладези. тем более, что с гостами не спорят

Ф>А вообще нужно читать. "Complete Code" Макконела.
а вот это как раз спорно и вообще не аргумент. хотя и гост тоже в споре не аргумент.