Saturday, 7 February 2015

Recursion and Test-ing

-D07, M02, Y15-

Top of the morning/day/evening to you! Now that I have raised my own spirits, I shall talk about recursion. I do not know what has occurred between last week and this week; yet somehow, writing recursive code has become clear--at this point in time of course. You simply implant your function or method with itself whenever you reach a point where the code might fail otherwise. Practicing writing the output of such code has not particularly helped me as much as actually seeing recursion utilized in more ways. And by different ways, I speak of sorting methods such as quick sort, as well as Stacks and Queues.

Even though I still cannot wrap my head around recursion (I get that it is similar to solving a problem inside another problem...but the fact that these are the same problem is truly astounding, especially since you have not finished solving the first problem in the first place), creating and using stacks and queues (which are simply program versions of what they are in reality) has been helpful. Although other students like Courtney here have had little trouble with these things, I admit that I abhor using techniques that I do not understand. Well, to a satisfactory degree, that is.

Besides this, we had a midterm this week in place of a lecture, testing on our understanding of recursion, inheritance, and class and method structuring. It was fair, and I believe I did well--especially because coding recursion was not on the test. In the future, I expect that we will learn some techniques involving raising Errors, 'trying' code, and other preventative measures to protect code from breaking in unusual circumstances.

And finally, the idea of unittest, where you write an entire separate file to test the extent of your code. At the moment, it seems excessive, given the ease of using doctest, which works within the code itself; nevertheless, I am sure that this will not be the case when we must code thousands of lines for a client or clients. The most difficult part of writing any form of test cases would be writing them to actually push your code to the extreme. I don't know why, but I really don't want to hurt my code. Being the creator of the code, you understand how it works, and it becomes difficult to deliberately try to misuse it in ways that should work properly. It is analogous to breaking in a shoe that you just finished making, except it might explode if done improperly.

Thanks for reading.

1 comment: