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

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

L>>Ага. Только completions в комментариях не работают (подумайте дважды, перед тем, как спрашивать зачем это надо, ладно?)

AJD>А серьезно, зачем?
AJD>Если для документирования, а-ля doxygen, то это все шоткатами генерится, включая имя и параметры. А еще зачем?
Банально в блоке \code..\endcode написать пример использования.

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

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

L>>То, что вы делаете в отладчике, легко автоматизируется юнит тестом, который затем включается в состав ночного билда и когда очередной Вася Пупкин организует в Вашем давно отлаженном коде очередной расстрел памяти, Вы, вместо того, чтобы с отладчиком наперевес трассировать всю систему (недельку-другую), просто выдадите люлей Васе.
WH>А если этот Вася автор сторонней либы? И живет этот Вася на другом конце планеты?
А это иррелевантно. Юнит-тесты показали, что в вашем коде все все еще ОК, но Васина либа косячит.
WH>1)Только не надо гнуть пальци и говорить что сейчас мы это поделье быстреньке перепишем.
А Вы предпочитаете оставить утечку памяти?
WH>2)Или найдем что-то лучше.
Вариант.

WH>Или скажем у меня была задачка по не тривиальной обработки сложных структур данных.
WH>Как написать для этого юнит тест я так и не придумал.
Слово "не могу" живет на улице "не хочу".
Знаешь, когда я пишу код, у меня первая мысль "а как я его буду тестировать". Применяя такой подход, можно половину намеченного кода, как говрят математики, свести к предыдущей задаче, т.е. использовать код, уже написанный для чего-то еще и соответственно уже оттестированный. Более того, если код таков, что натянуть на него юнит кажется невозможной или очень сложной задачей, это однозначный показатель того, что коду нужен рефакторинг.

Я тебе сейчас одну обидную вещь скажу, но советую над ней подумать. Если ты не понимаешь, как протестировать свой собственный код, ты не понимаешь как он работает.

WH>Единственное что пришло в голову это дампить эти структуры в очень не маленький текстовый файл, отсмотреть этот файл глазками, и положить в svn. Далие при помощи svn смотреть что меняется.
WH>Причем файликов таких было много и каждый из них был в разы больше чем весь код.
Подобные вещи покрываются автоматическими тестами на раз.
Вот когда отрастает необходимость тестировать что-то сетевое и проверить, а что, если "Вася Пупкин, разжалованный в уборщики, выдернет сетевой кабель", приходится подумать подольше. Хотя это тоже реализуемо.

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

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

C>>>Собственно, после работы с GDB я понял, почему люди считают отладочную печать лучше, чем использование отладчика. Просто она действительно намного удобнее GDB.
L>>Если только что написанный код надо отлаживать отладчиком, то таких "программистов" надо гнать в дворники ссаными тряпками.
C>Видимо, ты не работал с большими проектами. У меня очень часто при изменении твоего кода ломается какая-то другая библиотека.
Индикатор никудышнего тестирования кода.
L>>То, что вы делаете в отладчике, легко автоматизируется юнит тестом, который затем включается в состав ночного билда и когда очередной Вася Пупкин организует в Вашем давно отлаженном коде очередной расстрел памяти, Вы, вместо того, чтобы с отладчиком наперевес трассировать всю систему (недельку-другую), просто выдадите люлей Васе.
C>Юнит-тест позволяет диагностировать регрессии. С ними проблем нет, проблемы с новыми ошибками.
Индикатор никудышнего тестирования кода.
C>Например, у меня в проекте есть бибилиотека, которая занимается созданием прозрачного распределенного графа объектов, автоматически синхронизируемого с базой. Код почти на 100% покрыт юнит-тестами. Тем не менее, именно с этой библиотекой у меня всегда больше всего проблем — очень часто натыкаюсь на непредусмотреный в библиотеке частный случай. При этом приходится долго отлаживать код и следить почему именно структура объектов не так как надо получается. При этом, нужно одновременно отлаживать клиентскую и серверную части.
Попробуйте изменить подход к "покрытию юнит-тестами".
C>После того, как ошибка найдена — для нее пишется юнит-тест, но саму ошибку-то надо сначала найти. Отладочная печать для этого жутко неудобна — приходится перекомпилировать и перезапускать приложение, если нужно добавить новую точку наблюдения.
Бывает. Еще можно лог к программе приделать.

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

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

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

_O_>Вы какого типа и масштаба проекты делаете?

Большие и распределенные
здесь, верхние два, you'll get an idea.
Последней нашей системы там пока нет почему-то, но она целиком и полностью test-driven.

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

L>А это иррелевантно. Юнит-тесты показали, что в вашем коде все все еще ОК, но Васина либа косячит.
И? Проблема есть. Ее необходимо исправить.
А кто там накосячил это дело десятое.

L>А Вы предпочитаете оставить утечку памяти?
Я предпочитаю найти ошибку, пропатчить либу и отправить патч автору.
Ибо мне нужна система которая работает, а не стоять и крчать "Я тут не причем! Это все Вася!".

WH>>2)Или найдем что-то лучше.
L>Вариант.
Не вариант. На аналоги смотрели когда выбирали либу. Они еще хуже.

L>Знаешь, когда я пишу код, у меня первая мысль "а как я его буду тестировать". Применяя такой подход, можно половину намеченного кода, как говрят математики, свести к предыдущей задаче, т.е. использовать код, уже написанный для чего-то еще и соответственно уже оттестированный. Более того, если код таков, что натянуть на него юнит кажется невозможной или очень сложной задачей, это однозначный показатель того, что коду нужен рефакторинг.
Иногда не код такой. А задача такая.
Например у тебя на входе есть огромное дерево. И на выходе дерево но еще больше.
Писать код который сравнивает результат с тем что ожидалось?
Но это десятки если не сотни килобайт кода на каждый тест.

L>Я тебе сейчас одну обидную вещь скажу, но советую над ней подумать. Если ты не понимаешь, как протестировать свой собственный код, ты не понимаешь как он работает.
Я просто не хочу писать метры кода на ровном месте.
Ибо в них тоже может быть ошибка.

L>Подобные вещи покрываются автоматическими тестами на раз.
Ага... накатаем сотню другую килобайт исходников на каждый вариант...
Не проблема...

L>Вот когда отрастает необходимость тестировать что-то сетевое и проверить, а что, если "Вася Пупкин, разжалованный в уборщики, выдернет сетевой кабель", приходится подумать подольше. Хотя это тоже реализуемо.
Это гораздо проще чем сидеть и долбить ручками код который проверяет огромное дерево.
Это я тебе говорю как человек у которого в тз одним из первых пунктов идет: "Кластер должен работать если чать кластера физически выдет из строя."
И мои кластеры работают.

Так чем же плох вариант: Написать, отладить, сделать кучу дампов, отсмотреть их на предмет совпадения с тем что ожидали. После чего засунуть эти дампы в svn и автоматически находить регрессии.
Ы?

Кстати еще одна задача которую не понятно как тестировать: Автоматическое улучшение изображений.
Результат совершенно субъективен.
Объективные метрики полностью отсутствуют.

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

L>Ну научи, дорогой, как включить автодополнение кода, работающее внутри блока комментария.
Какой процент времени у тебя уходит на то чтобы набить код в комментариях? Что-то мне подстказывает что 0.1% максимум.
Какого еще сфероконя типа кода в комментариях и копирования ровно 100 строк выдумаешь?

Кстати кстати ты так и не ответил где логическая связь между D и C?

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

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

L>Большие и распределенные
L>здесь, верхние два, you'll get an idea.
L>Последней нашей системы там пока нет почему-то, но она целиком и полностью test-driven.

Повезло, если ваш тип проектов можно полностью покрыть unit-test-ами. Но это ведь не везде так. Я средства моделирования делаю, здесь и front-end сложен и back-end и интеграция одного с другим. Плюс еще многообразные интеграции со сторонними продуктами. В общем, без дебаггера все равно не обойтись.

C>> код для встроеных систем.
KP>тоже никаких проблем. логика с легкостью делается кросс-платформенной и тестируется на Win или Linux.

Кто бы меня научил писАть кросплатформенный код для Symbian... Расцеловал бы...

landerhigh wrote:
> C>Видимо, ты не работал с большими проектами. У меня очень часто при
> изменении твоего кода ломается какая-то другая библиотека.
> Индикатор никудышнего тестирования кода.
Еще раз напомню — код библиотеки покрыт тестами почти на 100% (по
результатам test coverage тулзов). Просто бывают достаточно интересные
случаи с конкуррентными изменениями, которые никто не предусмотрел заранее.

> C>Юнит-тест позволяет диагностировать регрессии. С ними проблем нет,
> проблемы с *новыми* ошибками.
> Индикатор никудышнего тестирования кода.
Угу. Вот бы мне еще кто пример замечательно протестированого кода
показал, который делает то же самое. Я бы свою поделку нафиг выбросил.

> Попробуйте изменить подход к "покрытию юнит-тестами".
Куда? В третий раз напомню — код библиотеки почти на 100% покрыт
тестами. Почему же мне не помогает эта магическая серебряная пуля?

> C>После того, как ошибка найдена — для нее пишется юнит-тест, но саму
> ошибку-то надо сначала найти. Отладочная печать для этого жутко неудобна
> — приходится *перекомпилировать и перезапускать* приложение, если нужно
> добавить новую точку наблюдения.
> Бывает. Еще можно лог к программе приделать.
Приделан. Ничерта не помогает. Тем более, что писать в лог сложные
графовые стркутуры — это еще то занятие.

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

L>Кто бы меня научил писАть кросплатформенный код для Symbian... Расцеловал бы...

я писал. в чем проблема? логика работала на Symbian, Brew, WinCE, Win32. Тестировалась на Win32.

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

L>>Кто бы меня научил писАть кросплатформенный код для Symbian... Расцеловал бы...
KP>я писал. в чем проблема? логика работала на Symbian, Brew, WinCE, Win32. Тестировалась на Win32.
На нативном Symbian'е? "Не верю" (с) Станиславский.

С Symbian'ом ничего больше не совместимо из-за их самопального механизма LEAVE'ов.

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

AJD>>Если для документирования, а-ля doxygen, то это все шоткатами генерится, включая имя и параметры. А еще зачем?
L>Банально в блоке \code..\endcode написать пример использования.

Обычно я этот кусок кода беру уже из готового рабочего примера, поэтому необходимость как-то не возникает

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

C>>> код для встроеных систем.
KP>>тоже никаких проблем. логика с легкостью делается кросс-платформенной и тестируется на Win или Linux.

L>Кто бы меня научил писАть кросплатформенный код для Symbian... Расцеловал бы...

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

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

L>>>Кто бы меня научил писАть кросплатформенный код для Symbian... Расцеловал бы...
KP>>я писал. в чем проблема? логика работала на Symbian, Brew, WinCE, Win32. Тестировалась на Win32.
C>На нативном Symbian'е? "Не верю" (с) Станиславский.

C>С Symbian'ом ничего больше не совместимо из-за их самопального механизма LEAVE'ов.

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

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

C>На нативном Symbian'е? "Не верю" (с) Станиславский.

C>С Symbian'ом ничего больше не совместимо из-за их самопального механизма LEAVE'ов.

еще раз повторяю — МОЖНО.
само собой это несет некоторые ограничения. но код выходит кросс-платформенный. основное было отказаться от диких симбайновских пойнтеров в пользу void*, но именно к void* пришли из за Brew.
а вообще логика была достаточно сложная (взаимодействие Филиповским Speech Recognition Server) и отображение полученных данных. Отлаживать подобное на Symbian было очень и очень накладно. Само собой для всех платформ был платформозависимый код. Главное грамотно разделить на компоненты.

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

KP>еще раз повторяю — МОЖНО.
KP>само собой это несет некоторые ограничения. но код выходит кросс-платформенный. основное было отказаться от диких симбайновских пойнтеров в пользу void*, но именно к void* пришли из за Brew.

Ты о чём? DesC?
А почему именно void*, что мешало обычные указатели использовать?

NBN>Пишешь код, придерживаясь своей или их системы исключений И мощный враппер для системных функций и библиотеки С. Фигня

Продай талант... Тьфу, не талант — враппер!

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

NBN>>Пишешь код, придерживаясь своей или их системы исключений И мощный враппер для системных функций и библиотеки С. Фигня

L>Продай талант... Тьфу, не талант — враппер!
L>)

Враппер для функций — NDA от LG

NBN>Враппер для функций — NDA от LG

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

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

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