Differences

This shows you the differences between two versions of the page.

--- debugging_20techniques_20_28lbb_29 [2018/04/03 15:59] – [[[https://ericlippert.com/2014/03/05/how-to-debug-small-programs/|How to debug small programs]]] jackkelly
+++ debugging_20techniques_20_28lbb_29 [2024/01/05 00:22] (current) – external edit 127.0.0.1
@@ Line 18: / Line 18: @@
 However, most semantic errors cause only an unexpected, undesirable result in the program output or behavior. These are the errors that are most difficult to find and correct. These are the errors that programmers really mean when they refer to a “bug”.
 =====Good Techniques=====
@@ Line 77: / Line 72: @@
 The previous scenario is an ideal oversimplification. This was a case when the error caused something observable to happen that was not expected. The opposite can also occur. The error could cause something NOT to happen that was expected. In this case you still need to set a breakpoint and look at the variables. But now you have to analyze the program logic to determine which line of code was supposed to make the action happen, and set the breakpoint there. Hopefully it is in the small module that you just added.
-Every program and every error is unique. There is no way to reduce the debugging process to a mechanical checklist. There are things we can do that are sometimes effective, but he debugging process is completely subjective. It depends on knowledge, skill, logic, observation, and intuition. Don’t be disheartened – it IS possible to debug, and even to enjoy it. Remember what they say, "If you truly like your job, you also like its mundane and difficult aspects too."
+Every program and every error is unique. There is no way to reduce the debugging process to a mechanical checklist. There are things we can do that are sometimes effective, but the debugging process is completely subjective. It depends on knowledge, skill, logic, observation, and intuition. Don’t be disheartened – it IS possible to debug, and even to enjoy it. Remember what they say, "If you truly like your job, you also like its mundane and difficult aspects too."
 ===== The Debugger =====
- The Debugger is a program that runs your program. It was designed and coded by world-class software engineers solely for your benefit. To run your program using the Debugger click the small bug button on the IDE toolbar, rather than the blue4button next to it that you usually use. The Debugger is fully described in the Help system. Search for ‘debugger’ in the Help topics window. Read the instructions, experiment with it, and try to understand it as well as possible before you try to use it to find a real program error. But, by all means, try to use it.\\ \\
+The Debugger is a program that runs your program. It was designed and coded by world-class software engineers solely for your benefit. To run your program using the Debugger click the small bug button on the IDE toolbar, rather than the blue > button next to it that you usually use. The Debugger is fully described in the Help system. Search for ‘debugger’ in the Help topics window. Read the instructions, experiment with it, and try to understand it as well as possible before you try to use it to find a real program error. But, by all means, try to use it.
 ===== Alternatives to the Debugger =====
- It is possible that you may find the Debugger to be a bit too much. The Debugger window lists ALL the variables in use by the program even though you are usually only interested in one or two of them for a particular error. And the Debugger window always seems to be in the way. It allows you to single step through your program, but I have never found this to be of much help.\\ \\  With a little more effort you can set breakpoints and use them without the Debugger. As mentioned previously, the ‘wait’ statement can be used as a breakpoint. In conjunction with a remark, it can easily be found again in a large program by using Search. For example: **wait ****’****xxx**. A downside is that it must be deleted or ‘rem’ed before the program can be run normally. Debugger breakpoints (‘Trace 2’ and left-margin, clickable breakpoints) are ignored when the program is run normally. The latter are not saved, though.\\ \\  With a little more effort you can also view the value of variables without the Debugger. Most of the time you will be correcting errors in GUI programs. You can make a temporary statictext control in an unused part of the program window, perhaps at the very top or bottom, and apply a small font to it. You can then print the content of one or more variables to it and be able to view them with no additional overhead.\\ \\  For example:\\ **statictext #win.debug, "Debug Line", 0, 0, 785, 17 …**\\ **#win.debug "!Font Arial 10" …**\\ \\ **#win.debug ”a$="; a$; ” n=”; n**\\ **wait ’xxx**\\ \\
+ It is possible that you may find the Debugger to be a bit too much. The Debugger window lists ALL the variables in use by the program even though you are usually only interested in one or two of them for a particular error. And the Debugger window always seems to be in the way. It allows you to single step through your program, but I have never found this to be of much help.
+With a little more effort you can set breakpoints and use them without the Debugger. As mentioned previously, the ‘wait’ statement can be used as a breakpoint. In conjunction with a remark, it can easily be found again in a large program by using Search. For example: **wait ****’****xxx**. A downside is that it must be deleted or ‘rem’ed before the program can be run normally. Debugger breakpoints (‘Trace 2’ and left-margin, clickable breakpoints) are ignored when the program is run normally. The latter are not saved, though.
+With a little more effort you can also view the value of variables without the Debugger. Most of the time you will be correcting errors in GUI programs. You can make a temporary statictext control in an unused part of the program window, perhaps at the very top or bottom, and apply a small font to it. You can then print the content of one or more variables to it and be able to view them with no additional overhead.
+For example:
+<code lb>
+   statictext #win.debug, "Debug Line", 0, 0, 785, 17
+   #win.debug "!Font Arial 10"
+   #win.debug ”a$="; a$; ” n=”; n
+   wait ’xxx
+</code>
 ===== MainWin =====
- If you need to see more diagnostic information than can fit on the statictext control, you can ‘print’ to the MainWin. For example array variables, which are not listed in the Debugger. If you need to see the contents of an array, you could put a temporary ‘for-next’ loop with a print statement before the breakpoint. When the program stops the array values will be listed in the MainWin. To do this you must ‘rem’ the ‘NoMainWin’ statement, and remember to un‘rem’ it before running the program normally.\\ \\
+ If you need to see more diagnostic information than can fit on the statictext control, you can ‘print’ to the MainWin. For example array variables, which are not listed in the Debugger. If you need to see the contents of an array, you could put a temporary ‘for-next’ loop with a print statement before the breakpoint. When the program stops the array values will be listed in the MainWin. To do this you must ‘rem’ the ‘NoMainWin’ statement, and remember to un‘rem’ it before running the program normally.
-===== Conditional breakpoints =====
- You might find that a line in a loop is possibly causing the error. Your program might loop through this line any number of times but analysis tells you that only the third iteration is problematic. You can set a conditional 'trace 2' or 'wait' breakpoint that will only stop the program on the third pass through the loop. For example: if n=3 then wait\\ \\  Left margin, clickable breakpoints can only be unconditional in the Debugger.\\ \\
-===== If all else fails =====
+===== Conditional Breakpoints =====
- If you've spent many hours and haven't been able to find the cause of an error or to correct it, then STOP. Take a break, do something else to get your mind off it, or get a good night's sleep. When you go back to the problem it's not unusual for the answer to jump right out at you. It happens all the time.\\ \\
+ You might find that a line in a loop is possibly causing the error. Your program might loop through this line any number of times but analysis tells you that only the third iteration is problematic. You can set a conditional 'trace 2' or 'wait' breakpoint that will only stop the program on the third pass through the loop. For example: **if n=3 then wait**
+Left margin, clickable breakpoints can only be unconditional in the Debugger.
+===== If all else fails... =====
+ If you've spent many hours and haven't been able to find the cause of an error or to correct it, then STOP. Take a break, do something else to get your mind off it, or get a good night's sleep. When you go back to the problem it's not unusual for the answer to jump right out at you. It happens all the time.
 ===== Debugging Exercise =====
 You have written a short program and it is working well.
+<code lb>
   NoMainWin
   WindowWidth = 800
@@ Line 126: / Line 145: @@
       end
   end sub
+</code>
 However, you decide it needs a small modification. You want to add a 'Pause' button which will stop the counting. Clicking the 'Start' button will resume the counting where it left off. I've made it easy for you to add your modification. Just un'rem' three lines -- one for the button, and two for its click routine.
@@ Line 132: / Line 151: @@
-===== Additional Reading =====
-\\
 =====Additional Reading=====
-[[http://redirect.viglink.com/?format=go&jsonp=vglnk_147664253334812&drKey=1134&libId=iucyt80w010004n1000DAlfkengsg&loc=http%3A%2F%2Flibertybasic.conforums.com%2Findex.cgi%3Fboard%3Dgeneral%26action%3Ddisplay%26num%3D1475998854&v=1&out=https%3A%2F%2Fblogs.msdn.microsoft.com%2Falfredth%2F2007%2F01%2F19%2Fprogramming-proverbs%2F&ref=http%3A%2F%2Flibertybasic.conforums.com%2Findex.cgi%3Fboard%3Dgeneral&title=Liberty%20BASIC%20Community%20Forum%20-%20Debugging%20Techniques&txt=https%3A%2F%2Fblogs.msdn.microsoft.com%2Falfredth%2F2007%2F01%2F19%2Fprogramming-proverbs%2F|Programming Proverbs]] =====
+[[http://redirect.viglink.com/?format=go&jsonp=vglnk_147664253334812&drKey=1134&libId=iucyt80w010004n1000DAlfkengsg&loc=http%3A%2F%2Flibertybasic.conforums.com%2Findex.cgi%3Fboard%3Dgeneral%26action%3Ddisplay%26num%3D1475998854&v=1&out=https%3A%2F%2Fblogs.msdn.microsoft.com%2Falfredth%2F2007%2F01%2F19%2Fprogramming-proverbs%2F&ref=http%3A%2F%2Flibertybasic.conforums.com%2Findex.cgi%3Fboard%3Dgeneral&title=Liberty%20BASIC%20Community%20Forum%20-%20Debugging%20Techniques&txt=https%3A%2F%2Fblogs.msdn.microsoft.com%2Falfredth%2F2007%2F01%2F19%2Fprogramming-proverbs%2F|Programming Proverbs]]
-This is an excellent series of articles by Alfred Thompson, a computer science educator. The articles are based on a book, 'Programming Proverbs', by Henry Ledgard. Each article discusses one of the 26 proverbs, followed by comments from various readers. It's clear to see from the comments the wide range of opinions that surround program planning, development, testing, and debugging.\\ \\
+This is an excellent series of articles by Alfred Thompson, a computer science educator. The articles are based on a book, 'Programming Proverbs', by Henry Ledgard. Each article discusses one of the 26 proverbs, followed by comments from various readers. It's clear to see from the comments the wide range of opinions that surround program planning, development, testing, and debugging.
+[[https://ericlippert.com/2014/03/05/how-to-debug-small-programs/|How to debug small programs]]
+This is an article by a very high-powered programming professional, Eric Lippert. He worked at Microsoft for many years. Although he seems a bit arrogant and cynical, one can't dispute his good advice.