Tuesday, May 12, 2015

Code, Compile, Test, Repeat

I came across this image on Facebook recently and it got me thinking. afraid to compile My first old guy “get off my lawn” thought was that when I started coding one was lucky if they had a chance to compile more than once a day. But of course timesharing and interactive coding and development came soon after and we started compiling all the time. Today’s developers can pretty much compile anytime they want even if some systems are put together and built less frequently.

Back in the day a simple typo could result in hundreds of errors and it it was a tedious and often difficult task to determine which errors were real and which ones would be fixed by correcting a typo. Today’s IDEs are a big help in this area and warn of all sorts of errors from uninitialized variables to “Possible mistaken empty statement[s].” Syntax errors are easier to spot and  generally development is a lot easier than it was in the punch card and paper tape era.

Students, and even more advanced developers, can still get into trouble by not letting the compiler (or interpreter) do what it does early and often though. What I see students do is to try and write the whole program at one sitting before trying things out. At this point it can become very difficult, especially for beginners, to determine where in the code a logic error may be found.

I encourage students to break a problem down into simple steps and test as they go along. I try to model this in my demonstrations with sample runs so that students can see partial results, find errors or missing steps, and then move on to making the program handle what ever is next.

For some students I think a problem is that their programs/problems are too small. By that I mean they can (or think they can) get their heads around it and complete it in a single step. They think if it as a simple paragraph writing assignment. In fact most are at least more akin to a 3 to 5 paragraph paper. That requires a bit more thought, a bit more organization, and even a bit more editing. A larger project such as a semester or year end project is more like a research paper. A longer paper is not (usually) written in one go. It usually starts with an outline that plans out the steps and organization of the paper. A larger program is much the same. Development works better if there is an outline – perhaps using calls to method stubs with descriptive names.

Once outlined a program can be filled in and the individual methods tested and refined (or at least debugged) before moving on to the next one. Students don’t always think that way though. It’s something we’ll talk about before they start their semester end projects in the near future though. I hope it sticks.

2 comments:

Mike Zamansky said...

I don't use an IDE, rather a highly customized Emacs install. Whether live coding or coding on my own stuff it's always save/compile/test on every concept - that is a loop, a conditional, a formula. One concept at a time.

I model it and also talk about it.

Maybe my compulsiveness w/r to this hearkens back to the days when idle hands would instinctively type "sync" in the Unix shell.

Garth said...

I try to beat this through my students sometimes thick skulls. Test every change in code. It is so easy to run with new IDEs that anything else is just foolish. One of my Programming I assignments involves drawing a tessellation with Small Basic. The kids will enter 20 lines of code at once and get junk when they run it. They then ask me to troubleshoot it for them. I delete 19 lines of code and tell them to test it. I too was in the punch card and limited compiling time era. There was something special about writing the whole program in one sitting and just hoping it worked.