|
|
|
|
|
by ampersandy
2599 days ago
|
|
The author fails to understand the true purpose of "debugging". It's not about finding and fixing a bad line of code. It is about broadening your understanding of a system and correcting faulty assumptions about how it works. Then applying this greater understanding to a) find and fix issues and b) avoid creating new problems in the future. Once you have extensive knowledge of how a system works, you can more easily spot incorrect code and are less likely to write it yourself. You should always treat any debugging session as "learning more about the system". If you can't explain to another person _why_ a bug occurred, then you won't be able to convince them that the problem is truly fixed. The approach you take to learn how the system works is not important, and will vary from person to person. Experienced developers can read code, think about it, and understand what it does. Some people understand control flow through print statements. Some people can fly through with a debugger. Saying someone else's method of study is "wrong" is just silly if in the end they understand how it works. This article is especially wrong because it makes the assumption that you must step through a program line by line when you use a debugger, which you don't have to do. You can just put breakpoints at the same places where you would have put an equivalent print statement, except now you can inspect _everything_, instead of the one or two things you bothered to print out. |
|
See Latin cilicium, French cilice.
http://www.newadvent.org/cathen/07113b.htm
These types of article stink of this to the heavens.