programming

A brief summary of unit testing

On 11.15.10, In programming, software, By Derek

In 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…)

Controlling your code through versioning

On 11.11.10, In programming, software, By Derek

In 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: best practices • principles • programming • software • teamwork

A matter of principles

On 11.10.10, In programming, By Derek

zeroes and ones In 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: best practices • principles • programming • software

An apologetic old program

On 04.26.10, In programming, By Derek

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: programming • software

How NOT to design programming code, part II

On 01.25.10, In programming, By Derek

(If you haven’t read part I, make sure to start there!)

After a night of hardcore, sloppy programming (a phrase that just missed being caught by my work’s naughtiness filter by a single word), we had a program that did the exact opposite of what we intended. Meaning: it didn’t do anything. The next day, my small group went to see our professor shortly before our project was officially due to get some last-minute help. After listening to our sob story and suppressing one’s natural instinct to laugh outright, he actually took pity on our hapless souls. Realizing that we had never before been put into such a situation and could learn a valuable lesson, he gave us some advice on how to fix our program and granted us a couple extra days to get our act together. Our professor’s advice essentially boiled down to this:

Scrap what we have and start over from scratch
Break the overall program down into chunks, and design each chunk individually

(more…)

Tagged with: methodologies • programming

A brief summary of unit testing

Controlling your code through versioning

A matter of principles

An apologetic old program

How NOT to design programming code, part II

Recent Posts

Archives

Categories

Good tech reads

Links