0
Цитата
As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two.
One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places.
Clicking over statements takes longer than scanning the output of judiciously-placed displays.
It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is.
More important, debugging statements stay with the program; debugging sessions are transient.
© Brian W. Kernighan, Rob Pike, "The Practice of Programming"
One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places.
Clicking over statements takes longer than scanning the output of judiciously-placed displays.
It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is.
More important, debugging statements stay with the program; debugging sessions are transient.
© Brian W. Kernighan, Rob Pike, "The Practice of Programming"
ваш подход - включать как можно больше отладочных сообщений в код, и читать логи или запускать отладчик и искать ошибку?
дебагером я пользуюсь крайне редко, стараюсь включать отладочную информацию в код, но мне не нравится что код становится плохо-читаемым. можно конечно как то прикрутить аспекты, но кажись они только для трассировки подойдут в данном случае, аспектами не пользовался, сказать не могу. Чарли, я знаю, ты аспекты юзал, насколько ты их задействуешь в процессе логирования?
делитесь опытом и идеями
