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

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

I>>>Может ты его боишься тронуть, учитывая твои слова про 200К на функцию ?
E>>Что-то не припомню. Ссылочку не дашь?

I>

I>>Приходилось иметь дело с кодом в 200 и более КБ причем на одну функцию. Код этот завязан на кое какие алгоритмы которых я не знал.
I>И что? 200 КБ на функцию ничего не говорит ни о качестве кода ни о сложности алгоритмов.

I>Интересно, 200 КБ кода это сколько метров бумаги ?

Не знаю. Это же был код из ТВОЕЙ практики?

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

I>>У тебя все в порядке ? С пятницы на субботу ты получил внятный ответ. Тебе его повторить ?
E>Я так понял, что ты сможешь ответить через 2 недели.
E>Я жду...

E>>>Обычно, если что-то тормозит, то это что-то профилируют и сразу увидят, что взорвалось-то. В один шаг так сказать.
I>>А если тормоза вылезли во время эксплуатации, что тогда ?
E>А какая разница?

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

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

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


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

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

I>>

I>>>Приходилось иметь дело с кодом в 200 и более КБ причем на одну функцию. Код этот завязан на кое какие алгоритмы которых я не знал.
I>>И что? 200 КБ на функцию ничего не говорит ни о качестве кода ни о сложности алгоритмов.

I>>Интересно, 200 КБ кода это сколько метров бумаги ?

E>Не знаю. Это же был код из ТВОЕЙ практики?

Зато мнение "200 КБ на функцию ничего не говорит ни о качестве кода " — твоё.

У меня мнение про 200 КБ нафункцию — говно. А у тебя " ничего не говорит "

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

I>У меня мнение про 200 КБ нафункцию — говно. А у тебя " ничего не говорит "

Ну и зря. Бывает длинный-длинный линейный код... Неприятно, но несмертельно...

Но это опять не про то разговор. 200К печатать не особо хорошая идея. Но если тебе интересно, это всего сотня страниц где-то...

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

E>Слушай, я опять чего-то не понимаю.
E>По идее анализ лога проблемного запроса или его профилирование -- это первая реакция на тормоза.
E>В случае взрыва qsort она уже и покажет, что проблема именно во взрыве qsort и состоит. Или у тебя какие-то другие подходы?

Мне как то везло и запросы могли тормозить по самым разным причинам

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

I>Мне как то везло и запросы могли тормозить по самым разным причинам

Конечно по разным. За этим анализ лога и профилирование и проводят, чтобы сузить круг. КОНКРЕТНО в случае взрыва qsort эти меры однозначно выявят причину...

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

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

SD>>Сорри что влезаю но меня подобные вопросы вполне интересуют я просто не заметил что народ от скобочек перешел к чему-то полезному.
SD>>Для начала я не вижу никакой пользы в распечатке кода. Совсем. Пробовал — не помогает. Много рисунков на бумажке с конфигурациями и как они влияют на части алгоримов — да. Я даже искренне жалею что в код нельзя вставить картинку.
E>Ну и вообще много чего нельзя вставить без геморра.
E>Но в любом случае писать картинки/заметки в коде или в данных — это примерно одно и то же. Мне просто удобнее непосредственно код комментировать.

дык картинки они к коду отношения почти не имеют. Писать код который работает с 1-2мя вещами экономически невыгодно. В итоге имеем семейство алгоритмов которое имеет много настроек и работает с разными данными. Чтобы понять какое сочетание данных и настроек из факториала выделилось и требует внимания нужно диагностировать конкретный случай. То есть цепочка данных + настройки + поток обработки данных. К коду это имеет отношение постольку-поскольку.

SD>>то юниттест идет лесом.
E>Суть тестов не в этом. Это некая гарантия того, что код всё ещё выполняет свой контракт. Полезно при рефакторинге, например.

мне можно это не рассказывать. Я про алгоритмическую часть а не про интерфейсы где много людей копается. Внутри подсистемы никто рефакторинг делать не полезет ибо сначала надо все случаи просто представить это как кубик-рубик разбирать на атомы чтобы сложить. Инварианты и пред/постусловия и так проверяются в коде и всегда и на временную сложность почти не влияют

SD>>Чего вы там с распечаткой делаете ?
E>Ну я доказываю про код разные факты. Обычно есть конкретная задача. Ну, например, найти причину какого-то поведения. Ну вот и доказываем разные факты про код, пока не докажем нужный
дык см выше.

SD>>Видел реальный случай — чел ползал по простыне кода 3 месяца. Расрисовал ascii псевдографикой и комментариями весь файл и ... ничего. То есть совсем.

E>Это, скорее всего, не то. Обычно ползать надо не по простыне, и недолго
дык если бы клиентам не нужен был HPC можно было бы заниматься эстетизмом и не было бы простыней где машине расписывается все до мелочей. Комментарии тут не помогут тк все равно придется разбираться.

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

E>>Ну я доказываю про код разные факты. Обычно есть конкретная задача. Ну, например, найти причину какого-то поведения. Ну вот и доказываем разные факты про код, пока не докажем нужный
SD>дык см выше.

Ну у вас не бывает что ли ошибок в алгоритмической части?

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

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

E>>>Ну я доказываю про код разные факты. Обычно есть конкретная задача. Ну, например, найти причину какого-то поведения. Ну вот и доказываем разные факты про код, пока не докажем нужный
SD>>дык см выше.

E>Ну у вас не бывает что ли ошибок в алгоритмической части?

ну зачем скипать весь текст чтобы увидев отсыл к нему задавать столько знаков вопроса?

повтор предыдущей серии:
Писать код который работает с 1-2мя вещами экономически невыгодно. В итоге имеем семейство алгоритмов которое имеет много настроек и работает с разными данными. Чтобы понять какое сочетание данных и настроек из факториала выделилось и требует внимания нужно диагностировать конкретный случай. То есть цепочка данных + настройки + поток обработки данных. К коду это имеет отношение постольку-поскольку.

То есть в коде реализовано много чего что реально происходит зависит от данных и настроек в точке Х. Разумеется ошибки могут быть начиная от спек и далее. Помню как ужаснуло когда нашел баг закрепленный юнит-тестом. Неудобно в тесте описывать сложную геометрическую ситуацию. Первый же взгляд на картинку (вот тут я и захотел вставку картинок в код) показал что ошибка в логике, но в простынке "кода" это осталось неочевидным, тк были десятки случаев правильных а этот нет.

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

SD>Писать код который работает с 1-2мя вещами экономически невыгодно. В итоге имеем семейство алгоритмов которое имеет много настроек и работает с разными данными. Чтобы понять какое сочетание данных и настроек из факториала выделилось и требует внимания нужно диагностировать конкретный случай. То есть цепочка данных + настройки + поток обработки данных. К коду это имеет отношение постольку-поскольку.

Не понимаю. Ну есть код, который запускается во многих режимах. Ну, казалось бы, вот в этом-то случае и надо его проверять ФОРМАЛЬНО, так как на уровне "общих рассуждений" обязательно прошляпишь какой-нибудь частный случай.

SD>То есть в коде реализовано много чего что реально происходит зависит от данных и настроек в точке Х. Разумеется ошибки могут быть начиная от спек и далее. Помню как ужаснуло когда нашел баг закрепленный юнит-тестом. Неудобно в тесте описывать сложную геометрическую ситуацию. Первый же взгляд на картинку (вот тут я и захотел вставку картинок в код) показал что ошибка в логике, но в простынке "кода" это осталось неочевидным, тк были десятки случаев правильных а этот нет.

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

Давай какой-нибудь простой модельный пример рассмотрим.
Скажем у нас есть выделялка связанных областей, которая параметризуется представлением и итератором изображений, представлением связанной области и определялкой локальной связанности (ну там 4-связанность, 8-связанность или что-то более экзотическое)

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

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

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

SD>>Писать код который работает с 1-2мя вещами экономически невыгодно. В итоге имеем семейство алгоритмов которое имеет много настроек и работает с разными данными. Чтобы понять какое сочетание данных и настроек из факториала выделилось и требует внимания нужно диагностировать конкретный случай. То есть цепочка данных + настройки + поток обработки данных. К коду это имеет отношение постольку-поскольку.

E>Не понимаю. Ну есть код, который запускается во многих режимах. Ну, казалось бы, вот в этом-то случае и надо его проверять ФОРМАЛЬНО, так как на уровне "общих рассуждений" обязательно прошляпишь какой-нибудь частный случай.

Ну "формально" проверять можно много чего и как. Если в коде отсутствует проверка предусловий/постусловий/инвариантов (даже если она отключаемая) то над исходником на бумаге можно разве что рыдать Так сказать практические наблюдения.

SD>>То есть в коде реализовано много чего что реально происходит зависит от данных и настроек в точке Х. Разумеется ошибки могут быть начиная от спек и далее. Помню как ужаснуло когда нашел баг закрепленный юнит-тестом. Неудобно в тесте описывать сложную геометрическую ситуацию. Первый же взгляд на картинку (вот тут я и захотел вставку картинок в код) показал что ошибка в логике, но в простынке "кода" это осталось неочевидным, тк были десятки случаев правильных а этот нет.

E>Казалось бы, если мы сразу писали код под формальную проверяемость, то и в случае бага формальные проверки должны быть полезны. А для формальной работы с кодом удобно иметь его распечатку. Ну мне удобно. Так скажем.

E>Давай какой-нибудь простой модельный пример рассмотрим.
E>Скажем у нас есть выделялка связанных областей, которая параметризуется представлением и итератором изображений, представлением связанной области и определялкой локальной связанности (ну там 4-связанность, 8-связанность или что-то более экзотическое)

E>Ну вот мы нашли, что что-то не так выделяется в каком-то частном случае. Нам надо понять, баг ли это выделялки или одного из параметров. Так?

Да, если рассматривать 1 функцию изолированно.

Но если взять и приблизиться еще на шаг к реальности могу привести иллюстрацию-пример над уже векторной геометрией. Есть операции : booleans( and, or, not ), cut, enclose, inside, interact, outside, touch, area, perimeter, extents, vertex_count ... Кто их будет делать независимыми формально проверяемыми функциями ? Это меняет оценку стоимости на порядок или даже на 2 так как и тестировать разную обработку с ними придется по новой и проблемы будут разные. А теперь зададим простой вопрос — а работает ли каждая из них над всеми данными или частью ? А части взаимодействуют ? Это только в идеальном мире вся геометрия лежит в одном массиве, все полигоны не самопересекающиеся и тп

То есть мой пойнт в том что рассматривать функции изолированно могут обладатели бесконечного времени и ресурсов. И читать код вместо того чтобы он сам проверил контракты просто не рационально.

Здравствуйте, Игoрь, Вы писали:

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

Pzz>>80 — это хорошая ширина. Не слишком большая, не слишком маленькая. Обычно если код не умещается в эту ширину, это свидетельствует о чрезмерном уровне вложенности. Разбиение такого кода на несколько функций помогает и ширину уменьшить, и логику кода сделать более внятной.

Pzz>>P.S. Кстати, экраны-то широкие появились, но слишком широкий код на принтере нормально не напечатаешь, а это иногда бывает полезно, чтобы с ним карандашом поработать

И>От блин, теоретики-рассуждатели.
И>

И>namespace BlahBlahaBlah
И>{
И>    class BlahBlah
И>    {
И>        public void DoBlah(FlowDocument original)
И>        {
И>            var sourceRange = new TextRange(original.ContentStart, original.ContentEnd); // <-- 88 символов
И>        }
И>    }
И>}
И>

а может, лучше так?
И>

И>namespace BlahBlahaBlah
И>{
И>        class BlahBlah
И>        {
И>                public void DoBlah(FlowDocument original)
И>                {
И>                        var sourceRange = new TextRange( original.ContentStart, original.ContentEnd ); // <-- куда больше символов
И>                }
И>        }
И>}
И>

а что, ширина экрана не проблема. зачем ужиматься?

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

И>>

И>>namespace BlahBlahaBlah
И>>{
И>>        class BlahBlah
И>>        {
И>>                public void DoBlah(FlowDocument original)
И>>                {
И>>                        var sourceRange = new TextRange( original.ContentStart, original.ContentEnd ); // <-- куда больше символов
И>>                }
И>>        }
И>>}
И>>

M_>а что, ширина экрана не проблема. зачем ужиматься?

Ну да, купил монитор в два раза ширше и все дела

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

E>>Я указал конкретную проблему. Взрыв QSort на каких-то специфичных данных. Чем там поможет подсветка и рефакторилка? Ну и вообще что именно поможет-то, кроме головы?

I>Сколько тебе лет ?

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

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

SD>Ну "формально" проверять можно много чего и как. Если в коде отсутствует проверка предусловий/постусловий/инвариантов (даже если она отключаемая) то над исходником на бумаге можно разве что рыдать Так сказать практические наблюдения.

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

SD>Да, если рассматривать 1 функцию изолированно.
Ну это же очень упрощённая модельная задача. Просто на моделе проще понимать друг дурга.

SD>Но если взять и приблизиться еще на шаг к реальности могу привести иллюстрацию-пример над уже векторной геометрией. Есть операции : booleans( and, or, not ), cut, enclose, inside, interact, outside, touch, area, perimeter, extents, vertex_count ... Кто их будет делать независимыми формально проверяемыми функциями ? Это меняет оценку стоимости на порядок или даже на 2 так как и тестировать разную обработку с ними придется по новой и проблемы будут разные. А теперь зададим простой вопрос — а работает ли каждая из них над всеми данными или частью ? А части взаимодействуют ? Это только в идеальном мире вся геометрия лежит в одном массиве, все полигоны не самопересекающиеся и тп
Казалось бы, это вопрос некоторого компромисса. Надо выработать некую обощённую модель операции, с какими-то её ограничениями, и реализовать. И пока наши частный случайне вышел за границы можели, что проверяемо формально, он должен соответсвовать всем её свойствам...

SD>То есть мой пойнт в том что рассматривать функции изолированно могут обладатели бесконечного времени и ресурсов. И читать код вместо того чтобы он сам проверил контракты просто не рационально.

Проверять контракты руками не стоит. Рками надо делать совсем другое. Проверять спеки, ну это в твоём случае.
У теюя ситуация ещё более располагающая к работе без компа, чем обычно.
Потому что, насколько я понял, есть некая довольно абстрактная модель обработки данных, которая наполняется реальным содержанием после того, как мы задали данные и параметры. Соответственно ошибки могут быть как на уровне этой абстрактной можели, так и на уровне её реализации, и на уровне параметризации этой реализации конкретными настройками. Так? Ну так искать ошибки в абстрактных уровнях реально только на бумажке как раз. И убеждаться, что их там нет тоже.

Правда тут есть ход. Можно сделать альтернативную, более абстрактную реализацию можели. Ну, типа на прологе каком, например. И иметь инструемтарий для отображаения реальной ситуации в модельную, и прогона там. Опять же можно из той реализации и из боевой писать лог работы абстрактной модели. И если абстрактная модель тоже падает, то значит, что проблема в модели. А если абстрактная работает, а боевая нет, то значит проблема в реализации. Что можно проверить сличив логи.

но это надо свосем уж хмурый уровень абстрактности иметь, чтобы разработка всех этих чудес оправдалась.
А пока всё не так плохо выход один -- бумажка...

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

I>>У меня были похожие задачи, получалось решать их используя инструменты.
M_>но при этом просто взять и привести конкретный список инструментов ты не можешь?

Раза три сделал. Ты вероятно хочешь, что бы я повторил специально для тебя все что здесь было сказано ?

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

итак краткое содержание предыдущих серий:
E>проблема — печатаем код

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

E>А пока всё не так плохо выход один -- бумажка...

Как тебе удается используя бумажку стимулировать мышление о проблеме ?
запускаемую модель я могу понять. с бумажкой — трудно