В смысле запустить код еще раз не помогло?
А как же тупо глядеть на код в надежде найти опечатку там, а не в своих генах
04.01.2019, 13:53
Ну если механическое запоминание ты связываешь с генами - у меня для тебя плохие новости.
ичх, неожиданно эффективный метод
Попадает под "подумать"
Спрашивать код "Какого хрена ты не работаешь? Что тебе надо, блять?"
Это на вторую. На третью -- варианты трудоустройства.
Тоже, в общем-то, дельные вещи.
Тоже, в общем-то, дельные вещи.
это называется запустить в другом окружении. И кстати это правильно, потому что на изменении косяка проще выловить.
На самом деле принт эффективен, когда надо проверить промежуточные данные, которые не хранятся и не ловятся в отладке.
Вот последний по эффективности метод это полная жопа. В тот единственный раз из тысячи, когда он может помочь, а ты не перезапустишь потеряешь кучу времени и нервов. И в конце разобьешь лицо фейспалмами. Так что лучше в любой не понятной ситуации перезапускать.
Вот последний по эффективности метод это полная жопа. В тот единственный раз из тысячи, когда он может помочь, а ты не перезапустишь потеряешь кучу времени и нервов. И в конце разобьешь лицо фейспалмами. Так что лучше в любой не понятной ситуации перезапускать.
Почему жопа? Всё равно для сложных багов придётся код запускать сотни раз. Один дополнительный погоды не сделает. Только я бы заменил на "запускаю код заново в надежде, что баг воспроизведётся". Потому что баги, которые воспроизводятся только иногда — вот это самый настоящий пиздец.
это когда сажаешь перед собой резиновую уточку и объясняешь ей что делает твой код
Обычная резиновая уточка для ванн. Или кот. Или тульпа. Или посторонний, который зачем-то смотрит, как ты кодишь. Все эти сущности обладают мистическим скиллом программирования: делать решение проблемы очевидным, если ты сумеешь им описать, в чём собственно проблема и на каком этапе она возникает.
А пользуются редко, потому что формулировать проблему почти так же лень, как и думать над проблемой.
А пользуются редко, потому что формулировать проблему почти так же лень, как и думать над проблемой.
Все не совсем так.
"Подумать" - это метод для школьников и студентов, у которых программа из 50 строчек, включая комментарии - попробуй-ка подумать, что пошло не так в сложном проекте из 200к строк. К этому методу следует прибегать в самом конце, когда ошибка уже локализована.
"Прочитать документацию" - это путь новичка, который эту документацию еще не помнит наизусть.
"Дебаггер" - это хорошее решение, но не везде доступное.
"1-я ссылка в гугле", - только в случае использования новых сторонних библиотек. Очень досадно, когда первая ссылка по проблеме - твоя собственная статья или начатая тобой пару лет назад ветка форума.
"Уточка для отладки", - это разновидность первого метода (подумать).
"5-я ссылка в гугле", - да хоть 10-я, если краткое описание показывает, что она больше соответствует твоей проблеме.
"printf", - это частный случай логов, а обмазываться логами - наиболее эффективный способ отладки там, где нет возможности использовать дебаггер
"запустить еще раз", - часто срабатывает в проектах, состоящих из множества раздельных приложений и/или имеющих какую-то разновидноть короткоживущего кеша.
"Подумать" - это метод для школьников и студентов, у которых программа из 50 строчек, включая комментарии - попробуй-ка подумать, что пошло не так в сложном проекте из 200к строк. К этому методу следует прибегать в самом конце, когда ошибка уже локализована.
"Прочитать документацию" - это путь новичка, который эту документацию еще не помнит наизусть.
"Дебаггер" - это хорошее решение, но не везде доступное.
"1-я ссылка в гугле", - только в случае использования новых сторонних библиотек. Очень досадно, когда первая ссылка по проблеме - твоя собственная статья или начатая тобой пару лет назад ветка форума.
"Уточка для отладки", - это разновидность первого метода (подумать).
"5-я ссылка в гугле", - да хоть 10-я, если краткое описание показывает, что она больше соответствует твоей проблеме.
"printf", - это частный случай логов, а обмазываться логами - наиболее эффективный способ отладки там, где нет возможности использовать дебаггер
"запустить еще раз", - часто срабатывает в проектах, состоящих из множества раздельных приложений и/или имеющих какую-то разновидноть короткоживущего кеша.
"запустить еще раз" - это если есть многопоточность. Там сидеть в отладке бесполезно, ошибка не воспроизведется. Да и добавление вывода в лог может нарушить тайминги и опять не воспроизведется. Приходится "запустить", "подумать", "запустить", "подумать"...и поставить критическую секцию.
Я все еще настаиваю на том, что вам не хватает третьего, Хуёвины.
