In Modeling and Simulation yesterday I presented my six R’s of debugging:<\/p>\n
Read<\/strong>: You have to read the code, and read what it really says, not what you think it says.\u00a0 You have to read the documentation, read the error message, and read the Stack Overflow page that comes up when you Google the error message.<\/p>\n But sometimes the bug is in your head.\u00a0 If the problem is your misunderstanding, you won’t find it by staring at the code…<\/p>\n Run<\/strong>: You also have to run the code, makes some changes, and run the code again.\u00a0 Sometimes when you clean up the code, and you make a change that should<\/em> have no effect, and it does<\/em>, that gives you a hint.<\/p>\n But don’t just make random changes…<\/p>\n Ruminate<\/strong>: Take time to think!\u00a0 What have you changed since the last time you had a working program?\u00a0 What is the program doing wrong, and what kind of error could cause it?\u00a0 What are you assuming that might be wrong?<\/p>\n Question everything, but don’t just sit in silence…<\/p>\n Rubber duck<\/strong>: You have to talk about it.\u00a0 Find someone who’s willing to listen and explain the problem.\u00a0 You might figure it out before they have a chance to say a word.\u00a0 In that case you don’t even need a person.\u00a0 A rubber duck will do.<\/p>\n Be persistent, but not too persistent…<\/p>\n