Unit test checkboxesIn my third of three related postings on some core programming principles, I’ll be talking about unit testing.  In the first part, we discussed code reuse, and in the second, I went over version control.

Unit testing is a methodology by which you run tests on individual bits of your programming code.  I have to admit that this is the topic of the three with which I am the least familiar.  The concept of “testing” in my past jobs has largely been comprised of this:

  • Write your program
  • Test it out as thoroughly as you can when done
  • Turn it over to a user for them to test thoroughly.

This is actually a very broad generalization, and I would, in fact, test out bits of code that I wrote as I wrote them, making sure that functions returned the desired results before I was anywhere near to having a final product.  While this is a step in the right direction towards unit testing, it is no means formal unit testing. (more…)

Tagged with:
 

Version ControlIn my last posting, I talked about the benefits of code reuse and how any good programmer should swear by that coding principle.  Today, I move on to another key programming methodology, that of version control.

Version control (revision control, source control, or any of a number of other similar names) is a method for archiving and documenting changes to programming code, web pages, XML files, and, frankly, any other type of file of which you might want to store multiple versions in one centralized location.  A benefit of this is that multiple programmers can work on the same code base without interfering with each other, and that you can easily track or back out changes to a file and go back to an earlier version, should a new change cause problems. (more…)

Tagged with:
 

A matter of principles

zeroes and onesIn the more than a decade that I’ve been programming, I’ve found that there are three programming principles that I really wish were included in the computer science program that I enrolled in during the late 1990s:

  • Code reuse (the DRY principle)
  • Implementing version control
  • Unit testing your code

There’s really no excuse for these topics not being covered, but it perhaps reflects upon how the academic world differs from the professional business world.  Academia considers you successful if you’ve studied all sorts of general aspects of computer science, while success in the business world requires following general coding principles, and not necessarily a grasping a thorough understanding of say, machine code or Artificial Intelligence (of course, my argument falls apart if you are designing computer processors, robotics, or video games!).

Covering all three topics in one article would be a bit much, so I’m going to split this up over the course of a few days. (more…)

Tagged with:
 

language bubbleWhile doing some research into one of the more recently hyped techs-of-the-moment, node.js, I came across this quote from debuggable:

“Another reason is JavaScript. You can use node to share code between the browser and your backend. JavaScript is also on its way to become a really universal language. No matter if you did python, ruby, java, php, … in the past, you’ve probably picked up some JS along the way, right?”

I’m not sure that’s a very compelling reason on its own to use node.js, but the author’s point is that most people know some JavaScript, so if you wish to use an evented programming framework, node.js is a wiser choice over, say, Ruby’s EventMachine, assuming you are more familiar with JavaScript than Ruby.

Regardless, I was fascinated by the part of the quote above that mentions how JavaScript is on its way to becoming a universal programming language.  There are lots of similarities between programming languages and spoken languages, with my personal favorite being how after you’ve picked up at least two languages, you can pick up virtually any after that very easily. (more…)

Tagged with:
 

An apologetic old program

This gave me a good chuckle — I ran into this recently on the old systems I still work on (yes, this comes from a terminal session!):

          Transaction Editing Database
              Charge Batch Proof

THIS ACTIVITY PROVIDES DETAIL VOUCHER INFORMATION BY
SELECTED BATCH NUMBER(S).

     HOW DO YOU WANT YOUR BATCH PROOF SORTED
               A. BY NUMBER
               B. BY PATIENT

          PLEASE SELECT A OR B : B

Sorry this portion of the program is being fixed !!!

Please selection A from the option menu.

Thank you for using the TE Batch Proof System

In short, I selected option B, only to be presented with the last three lines above.  This program first apologizes that B is not a working option and is currently being fixed (which is news to me – the last time I can tell that any programmer did any significant work to it was 10 years ago).  Then, it directs me to option A (why even bother listing an option B in the first place?).  And then perhaps my favorite part, it thanks me for using this system, apparently not realizing that it neglected to produce any useful output for me.

So, apparently, what we can learn from this is that if you don’t plan to eventually finish your program, at least make it sound like a pleasant convenience store worker.

Tagged with: