Monday, September 10, 2012

Parents, Non-public Methods and Eyes

Only now have I developed a greater appreciation for parent classes and private/protected methods. Besides hiding implementation details and reusing logic, they turn out to be very more useful than just that.

Last week I was updating a module and I was really having a rough time following the logic. I was troubled and stopped for a moment wondering why I'm having difficulty understanding code I myself had written just days before. Then I had an epiphany.

I loathed breaking down functions (or procedures if you will) in the past. I wanted everything to be in one place as much as possible, believing that avoiding those extra calls will make some huge difference in execution performance.

I, too, have tried many styles and methodologies over the years of programming and took some ideas that generally worked out for me. However, there are three particularly interesting ideas I've read before but never gave much thought:

  1. In Perl, you have lots of shortcuts that allows you to write programs that don't take up more than a screenful of lines
  2. If you're moving your eyes too much when reading a line of code, you would do well to break that and rewrite than line
  3. A person's eyes look up when that person is engaged logically, and you can also tell whether he/she is mental constructing or recalling depending on which side the eyes lean

OK, the third one isn't really a programming thing but something I picked up in Nursing.

So there I was moving my eyes all over the screen left and right, scrolling back and forward, looking up then back to the screen. Aside from the activity being stressful to the eye muscles, it was also stressing my thought processes. No wonder I was having difficulty 'visualizing the process', or going with the flow as one would say.

I then proceeded to re-factoring the module with the following thoughts:

  1. If a line is lengthy or nearing the edge of the screen, break it up
  2. If a function doesn't fit on your screen, break it up. You can tolerate up to three levels of nesting, more than that you usually need to rethink your approach
  3. When you already have a handful of functions (and class variables) for support purposes, like say for formatting or conversion that aren't needed much to understand what your class strives to do, move them to a base class

When I was done, I had a module that I can read like plain English. I no longer have to scroll back and forth to figure what's being done. Couple with string search, I can quickly locate where a particular problem is. Picking out a bug is easier than before because I don't have too much to look at a time.

Logically, I no longer have to look up a lot.

Saturday, September 1, 2012

Trip and Perl

It had been pretty busy the last few weeks. Never had time for playing around the lab. However, I had fun particularly at our company's team building activity. It was held in Samar, and it is a beautiful place there.

Yup, that's the Coding Avenue team right there in Caluwayan.

It was a good experience, and once again been reminded of my biggest bane... communication. As a child, I was always keeping to myself when hacking a problem and easily irritated when interrupted. Hrrmm, a very unsociable kid back then I was.

Well, what made me knowledgeable also turns out to be a problem. I've been keeping tabs to overcome this problem.

Anyway, through the trip I managed to finish reading 'Learning Perl'. I'll be looking for exercises to pound my Perl senses back, might also look at joining a project too. Here's a nice collection of Perl videos for anyone reading this: