After a week working on the scenario tests for handling Markdown with tab characters in it, I am convinced that the preparation time I took in getting ready for this block of work on the PyMarkdown project was the right choice. It was by no means easy work, but I firmly believe that I was able to make more progress because of the time I took to refactor.
That assertion is based on my observation that I found it easier to navigate around the code when I was looking for patterns. For those that have not read about my seemingly arcane debugging practices, I use a lot of log files for projects such as these. From my perspective, debuggers are great at providing a close up view of what is going on, but cannot display the information that I need to spot patterns. That big picture view is where I tend to use log files as a debugging tools.
For issues like fixing the handling of tab characters in the tokens, I find it invaluable to be able to examine the log files, looking for the ebb and flow of the data as each line is parsed and tokens are emitted. During this task of placing the tab characters back into tokens, I have often resorted to tracking the flow of data between two log files. On one monitor I have an editor open with the actual scenario test that I am debugging, and on the other monitor I have another editor open with the “spaces only” version of that test.
Basically, if I have the logs for one scenario test for a sequence like {space}{tab}
on one monitor, the other one contains the logs for the test with the sequence
{space}{space}{space}{space}. By making only that change to the scenario test,
I can examine the log files and see where the handling diverges. While it might
seem boring (because it usually is), it is effective. As an added feature, when
I think I have narrowed down the issue to a specific section of code, using a
statement like assert False in the offending code stops the processing cold.
That action just helps me not get frustrated at having to go through too many lines
in the log files.
While the log files do not help me clean up the code, they do help me isolate the code that causes the issue. And if the last week’s experience keeps paying dividends, it is because I can then deal with smaller objects once I find the area to focus on. Even with a good grasp of logic and programming languages, there are a finite amount of objects one can keep in their head at time. If I had to take an educated guess based on further observations, I would guess that by having smaller methods with better names helps me to “hold” on to the methods and their purposes better. If that is the case, it would then follow that I would retain that information better due to that grip.
I am not sure it that makes any sense. Refactoring and observations are funny things. What may look cleaner and obvious to one person may look the exact opposite to someone else. One thing I am sure of is that the pre-work helped me with this work, and for that I am grateful.
Comments
So what do you think? Did I miss something? Is any part unclear? Leave your comments below.