Marathon Coding

I love doing what I may call marathon coding:

Code one functionality you are going to implement from start to end. If the functionality means that you have to create a very big class from start to end, then do it. DO NOT debug or try to run the program before the functionality you desired is exactly implemented. The threshold is that your program will be able to produce the output you desired by the specified input. Doing debugging in the middle of your coding can distract your focus on implementing your functionality into real code. So just omit the debugging until the threshold is met.

You may also omit some of exception handling during this phase. In Java programming, this means that you have to catch every checked-exception and re-throw it as RuntimeException. This will ensure that any error inside your library will be brought up to the surface. Structured and well-formed exception handling takes time to do, so we can do it after the implementation is completed. But in a case that an exception handling is inclusive in the program flow, you must do the exception handling in this phase. It’s all on your judgement on how you design your program flow.

After completing all the codes for the functionality, you may start debugging. Start debugging by testing it in the program. Don’t expect that your program will smoothly run in the first time. If so, then it’s a luck for you, you might be very smart. If not, check every exception information, and locate the exception in the program line. Repair the program and restart the debugging. Do that until the program flows smoothly.

After first debugging is completed, you have to continue debugging based on specific input to your program. This to make sure that your program will be able to produce the desired output to every positive input correctly. After every possible positive input is debugged, you may start the development of exception handling for every negative input.

Developing a well-formed exception handling is quite cumbersome. But it is great to maintain the structure of the program. One of well-formed exception handling characters is that the Exception classes are tied into a multi-level Exception inheritance. You may create your own Exception class and create the structure on your own, and this is good practice.

Why I am talking about this? Well because I just did this kind of coding again today. I coded straight for 2 hours, typed about 260 lines of code, 20 minutes of debugging a positive flow, an implementation of simple one-way data binding that I can use in Android. Yes. Android does not provide a simple data binding out-of-the-box like what provided by ASP.NET or WPF or Java Swing (does it?). So I had to do my own boilerplate implementation of one-way data binding to simplify my coding in Android. Way too overkill, maybe, but fun. 😛 And I would not have to do much repetitive code for setting my TextView’s text from my data model.

I will share that code next time 🙂