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

S> Чистый код должен покрываться тестами

Большой вопрос, нужно ли писать эти тесты вообще! И насколько ты квалифицирован, чтобы ответственно заявлять, что после твоих тестов код 100% не содержит багов.
Одно дело — написать процедуру обновления счётчика, другое — обложить эту процедуру ТАКИМ количеством тестов, что даже бит не проскочит! Последнее требует квалификации на порядок большей, чем твоя процедурка. Уверен, что ею обладаешь??
Ну, это не говоря о том, что далеко не все вещи требуют тестов или вообще тестируемы. И последний гвозь в крышку тестов, есть ли у вас столько РЕСУРСОВ, что на 10 строк кода ты самоуверенно садишься писать 1000 строк тестов.

B>Большой вопрос, нужно ли писать эти тесты вообще!
Полезно. На всякое изменение кода иметь возможность 1 нажатием проверить "вообще всё", что когда-либо умели проверять.
>И насколько ты квалифицирован, чтобы ответственно заявлять, что после твоих тестов код 100% не содержит багов.
Сказать "успешно исполняет типовые сценарии" — уже весьма немало.
B>Одно дело — написать процедуру обновления счётчика, другое — обложить эту процедуру ТАКИМ количеством тестов, что даже бит не проскочит! Последнее требует квалификации на порядок большей, чем твоя процедурка. Уверен, что ею обладаешь??
Статусные игры какие-то. Тестировать надо не код, а решаемые задачи. Чтобы сдача заказчику приближалась и рекламации уменьшались, а не чтобы всяким оценщикам квалификации было где нос подточить.

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

S>Встречались ли вы с идеей, что дебаггер использовать не стоит

Не пользуюсь дебагером. Пишу логи.
Когда ищу баг — обкладываю все вокруг fprintf'ами, которые потом удаляю.

S>Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.

Юнит-тесты вещь безусловно хорошая.
Но на все случаи — ненужный оверхед.

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

G>Не пользуюсь дебагером. Пишу логи.
G>Когда ищу баг — обкладываю все вокруг fprintf'ами, которые потом удаляю.

Ну нормальный дебаггер и это тоже умеет, только удалять потом не надо. И код перекомпилировать для изменения. Логпоинт называется.

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

G>Не пользуюсь дебагером. Пишу логи.
G>Когда ищу баг — обкладываю все вокруг fprintf'ами, которые потом удаляю.

А в чем профит?

S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
Не только встречались, но и сам работаю практически без отладчика.
Отладчик мне требуется только в двух слукчаях:
1. Пройти по чужому незнакомому коду, посмотреть что за чем и когда следует. На новой работе вот как раз пришлось полазить java-коде.
2. Сложный баг, который "руками" не обнаруживается. Это бывает очень редко.

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

S>А в чем профит?

В возможности не переключать контекст на настройку дебажного окружения.

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

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

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

G>>Не пользуюсь дебагером. Пишу логи.
G>>Когда ищу баг — обкладываю все вокруг fprintf'ами, которые потом удаляю.

S>А в чем профит?

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

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

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

S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.

Тут топики на тему приключаются регулярно.

S>Каково ваше отношение к данной идее?

Из области юношеского максимализма.

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

S>> Чистый код должен покрываться тестами
B>Большой вопрос, нужно ли писать эти тесты вообще!

Я в тебе не сомневался.

B>Ну, это не говоря о том, что далеко не все вещи требуют тестов или вообще тестируемы.

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

B>И последний гвозь в крышку тестов, есть ли у вас столько РЕСУРСОВ, что на 10 строк кода ты самоуверенно садишься писать 1000 строк тестов.

Строки кода не стоят ни"№я. Ценность имеет качественное решение проблемы. И тесты — немаловажная часть этого решения, ничуть не менее важная (а иногда, например в случае компиляторов, более важная) нежели покрываемый этими тестами код.

G>Не пользуюсь дебагером. Пишу логи.
G>Когда ищу баг — обкладываю все вокруг fprintf'ами, которые потом удаляю.

Иногда можно даже не удалять, а закомментировать. Хотя на первый взгляд кажется, что этот мусор засирает код. Но оказывается — такие закомментированные fprintf'ы тоже могут быть полезны как дополнение к другим комментариям. Они показывают, на что следует обратить особое внимание. И на случай, если в будущем в поведении этого кода обнаружится неведомая хрень — будет примерно понятно, что снова надо вывести в лог, чтобы эту хрень отловить.

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

K>Иногда можно даже не удалять, а закомментировать.

Какие-то оставляю закомментированными подольше.
Но если, к примеру ищу где сегфолтится, тупо бинарным поиском ищу. Обкладываю чуть не через строчку, а потом подчищаю.
И всегда без отступов, чтоб удобнее удалять и не перепутать, типа такого:

#define LOG(s) fprintf(stderr,"%s %d:%s\n",__FILE__,__LINE__,s);
...
LOG(0)
    for(...){
LOG(0)
        if(...){
LOG(0)
            ...
        };
    };

K> И на случай, если в будущем в поведении этого кода обнаружится неведомая хрень — будет примерно понятно, что снова надо вывести в лог, чтобы эту хрень отловить.

А на этот случай лучше ассерты использовать.

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

В нормальных языках для этого можно (и нужно) использовать tracing.

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

S>Каково ваше отношение к данной идее?

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

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

S>Каково ваше отношение к данной идее?

Любую хорошую идею можно довести до абсурда.

Тебе так некоторые скажут, например, что TDD, где тесты не пишутся до кода — это и не TDD вовсе.
Что комментарии не нужны, т.к. хороший код — самодокументируемый.
Что код не только отлаживать не нужно, но и профилировать тоже, ибо "хороший код всегда написан максимально эффективно".
Далее можно прийти к тому, что код и запускать для проверки не обязательно, т.к. "этот код идеален и не содержит ошибок"
И т.п.

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

S>Каково ваше отношение к данной идее?

идиотская идея вкинутая идиотом

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

Пару лет назад был срач на эту тему -- http://rsdn.org/forum/flame.comp/7717305?tree=tree

Автор: landerhigh
Дата: 29.04.20

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

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

S>достижимо да и сложно, т.е. нужно быть крутым спецом в этом деле. Далее, как без отладчика находить и воспроизводить баг в многопоточной программе?

В многопоточной? А разве в этом случае как раз не проще писать в логи? В отладчике будет прыгать между потоками.

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

S>>достижимо да и сложно, т.е. нужно быть крутым спецом в этом деле. Далее, как без отладчика находить и воспроизводить баг в многопоточной программе?
S>В многопоточной? А разве в этом случае как раз не проще писать в логи? В отладчике будет прыгать между потоками.

В отладчике потоки можно оттормаживать, т.е. замораживать, походил одним, поставил на паузу (freeze), походил
другим (freeze), разморозил пред. поток (thaw) и т.д. Можно понять, где race condition, где забыли поставить lock
и т.п.

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

S>В отладчике потоки можно оттормаживать, т.е. замораживать, походил одним, поставил на паузу (freeze), походил
S>другим (freeze), разморозил пред. поток (thaw) и т.д. Можно понять, где race condition, где забыли поставить lock
S>и т.п.

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