Debug techniques based on bitter experience (see 8 below)
1: Write perfect code.
Then you will never, never, ever need to debug.
Very, very, very few people on this planet have this ability.
Maybe you know one?
Maybe PeterNLewis is one?
I do not know, but I do know I am not one of them.
2: When you have sketched out your code, then think how you will test it, BEFORE you start writing it or testing it.
The analogy I would use is that you are playing a game of chess.
You have the White pieces.
The opponent is has the Black pieces.
You carefully analyse the position from the White perspective.
THEN, to test, you walk around to the other side of the board and look at the situation from the Black perspective.
i.e. you change your point of view and try and see how you will test this.
This will often throw up things you have not thought of because you are looking at it from a different point of view, typically unusual conditions, initialisation problems, race conditions, semaphore conditions etc.
3: Explain what you are trying to do to an imaginary dog, cat, or third person.
This makes you formulate the problem in a different way often leading to an “Ah-Ha” moment.
You do not need the dog or cat or whatever, it is just a question of changing your perspective on the problem. (I used to explain to my wife, but she used just carry on ironing, and ignore me completely, but it did the trick). If you are in an office, a fellow programmer or the office coffee machine is a suitable substitute.
4.Go for a walk round the block, do something else, and comeback to the problem later, sleep on it. Again it is a question of having a different perspective or a fresh look.
- Redefine the problem. If solution A is not working, then rewrite as a different solution
e.g. assume you had to print the three times table from 1x3, 2x3 then the alternative solution would be print the 4 times table from 12x4 to 1x4 i.e. the same problem modified.
6a. Redefine the complete problem. Ie make it more generic e.g. tables 1…12 x 1…12
6b Redefine the complete problem. Ie make it more specific.
-
Create test cases and scenarios and see what would happen
-
Goto the pub and have a pint ( my personal favourite)
===================================
- Keyboard Maestro debug specifics.
9.1 Check you have not mis-spelt a variable name.
9.2 Add start and stop debug statements at key points
9.3 Change the name of Instance and Local variables to GLOBAL by adding say xx as a prefix.
e.g. Instance_loop_count_n becomes xxInstance_loop_count_n and therefore will appear in the Global variable list. Later, you remove the xx.
9.4 Create a debug macro that just consist of Display text in a window of ALL the variable names you are using. (This will not work for Local variables, so make all your variables either global or Instance unless it really really is a local variable) e.g. “Var123” >>> Its actual value so you know what is what. The advantage of the debug macro is that you can include at ANY point in the macro under test, but the variables must be global or Instances….
9.5 Do NOT do complicated functions in KM function calls
e.g. instead of say MOVETO( sqrt(var1 x var2) / var3)) do
temp_var = sqrt(var1 x var2) / var3)
MOVETO(tempvar)
then you can check on the value of temp_var
9.6 the KM debugger advances to “Nextstep”
You can “force” it to stop at intervening points by inserting dummy statements as
temp_debug_point is set to text “ I am now here”
code ~~~~~~~
temp_debug_point is set to text “ I am now here2 ”
code ~~~~~~
temp_debug_point is set to text “ I am now here3”
This stops the KM macro debugger running away and you know exactly where you are
This can be enhanced by
temp_debug_point is set to text “ I am now here3:: var 88 = %Variable%var88%
so you know the intermediate value.
9.7 XML. Save the macro by exporting to .kmmacro format i.e. XML.
Open the macro using an XML editor e.g. Atom.
This will enable you to search for specific strings especially if you have a variable name mis-spelt
9.8 Use KM> Prefs> variable and clipboard as these are updated in “realtime” as the macros is run.
9.9 It is remotely possible it is not your fault i.e. a bug in OSX, but in my experience this is rarely the case.
9.10.When all else fails ask JMichaelTx or one of the other major contributors to this forum.
I am going to rebadge myself as Caspian as Sleepy has been taken.
9.11 Here are some quotes from HitchHikers Guide to the Galaxy which are worth remembering, after all, it is only a “bug”.
9.11.a. “Funny,” he intoned funereally, “how just when you think life can’t possibly get any worse it suddenly does.”
9.11.b. The chances of finding out what’s really going on in the universe are so remote, the only thing to do is hang the sense of it and keep yourself occupied.
9.11.c. A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
9.11.d. Not unnaturally, many elevators imbued with intelligence and precognition became terribly frustrated with the mindless business of going up and down, up and down, experimented briefly with the notion of going sideways, as a sort of existential protest, demanded participation in the decision-making process and finally took to squatting in basements sulking.