"I'm really really good at #debugging" a #sap #abap developer friend once said to me. I replied "oh thats awful". Why? Because it means he spent a lot of time finding bugs in code that was probably not covered by tests. But how do you debug efficiently? (1)
Many people use breaks points, watchpoints, breakpoints on messages, exceptions, post mortems, job debugging, etc and are successful that way. But at some point you have to "look at code". Over the years I've seen a few repeating patterns: (2)
"Just go for it". Is the error reproducible at all? Before debugging, it is better to check that, otherwise you lose a lot of time with code in which the error is not / only difficult to see by debugging. Because everything works as it should durching your debugging session. (3)
"No clear target" It is not clear what is the wrong output of the coding and what should be the right one. This makes it difficult to analyze the code. What is supposed to be the ouput if the program would work correctly? (4)
"Jump into every method call". You can do that, but you will read a lot of code that is not relevant for your problem. Better first look at what the method returns and if that looks suspicious, then take a closer look at the method. (5)
"Hoppelhase" In a 300 lines method each ABAP command gets checked individually and each variable value gets inspected. This costs a lot of time. From my point of view a better solutions is "binary search": (6)
Set a Breakpoint in the middle of the method. If you get there without problems (dump, exception, empty tables etc.), the error is probably not in the upper half of the method, but in the lower half. So you can "triangulate" your way to the problem. (7)
"Hoppeln instead of reading". Jumping individually through each line of code. You can also read the code crosswise first. Maybe someone has named a variable well or left a comment that helps? Often you know roughly what the problem could be. (8)
Why not read the code first and then set breakpoints at suspicious places? (9)
"no list of common problems in mind". there are repeating causes for errors: internal tables are empty, > instead of <, from- and to-date swapped, no CLEAR, SY-SUBRC being ignored, IF without ELSE, etc. It helps to have these issues in mind while reading through code. (10)
"unit tests? what unit tests?" Sometimes there are unit tests (surprise, surprise) and they can help us to understand the code, reproduce the problem or they even show the error directly. (11)
"Fighting alone" Debugging is very exhausting - four eyes see better than two. Software development is a team sport. (12)
"Debugging a lot while developing new features" Well it is something you can do, but it costs a lot of time. Ever tried unit tests? Often you can avoid debugging completely, especially if you use scaffolding tests for new coding. (14)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
