Teach yourself programming, Part 2

Sequel to part 1 of the TYP series.

Image of Michal Young, Assistant professor at UO

You'll see a lot of professor Young if you go to UO.

For part 2 of this miniseries, we’ve got some sagely advice from Michal Young, the Associate Professor of Computer Science at University of Oregon. And you know he walks the walk too, since he’s written and published a textbook.

The thing about programming is that it’s a lot like language. You learn the language, and then learn to combine the things you know to make completely new ideas (or programs). If you’ve programmed before, you know the grammar is a bit more strict in programming (forget one period and the computer might explode, or crash. One of the two). Like language, you’ve got to use it a lot to become a master. But along the way, some people develop bad habits. Just like you might notice some people write ‘alot’ instead of ‘a lot,’ or they forget to capitalize letters.

They’re typically fairly minor things in regular language—we can forgive them—but in programming these kinds of flaws can lead to inefficient code, which can cause bugs or slow down a computer. So naturally it’s best to try to break the bad habits before they form. A few of the big ones I learned of, while talking to Professor Young:

  • Commenting
  • Function clarity
  • Variable, function or class naming

I’ll go into some detail on these, guided by his words, in a sec. First I want to say that good programming is very zen, in my experience. Like playing a game of chess. It requires a lot of forethought, and the whole time you have to be thinking about the endgame. Thinking of the next step simply isn’t enough. Every move you make will affect every other.


“Our primary audience is other programmers, not the computer.”

It’s not always easy for us to remember that the purpose of a particular piece of code isn’t obvious to everyone. A well-named variable (we’ll get to that later) can usually give you a good idea of what it’s for, but sometimes even typing dateUsed for a variable name won’t help us know which date is being talked about, or what functions use that. A well-commented piece of code lets you know what uses it, why it’s used, and basically where that variable fits in the grand scheme of things.

Function clarity

“Functions, or ‘methods,’ ‘procedures,’ whatever, must each have a single clear purpose.”

A function is the basic unit of getting-things-done in programming. Every function should do a job. Some people think it’s easier to make one function that does the whole job. For example, let’s say you want to take a list of names from a text file, alphabetize them by last name, and then print them.

If you want to have well-made functions, you would have one function to generate the list from the text file (or maybe even one to read the data, and another to turn it into a list), one function to alphabetize them, and one to print. One of the basic concepts of programming is that you break a big job into a lot of little jobs, then write functions to do those jobs, and then join all the functions together to do that one big job. But you’ve got to break it down for the same reason we like breaking textbooks into chapters, and into sections. If it was just a ton of text nobody could read it, and it would be useless.


“We use naming conventions to remind us which names refer to variables, which to classes, which to global constants.”

Naming convention in programming is pretty straightforward. Basically, they’re sets of rules you follow when naming stuff so that, when someone else looks at your code (or you do, sometime in the future) everyone knows at-a-glance what some name is. Can you spot the differences?

  • CoffeeMug
  • coffeeMug
  • coffee_mug

It’s pretty easy to tell. And to a programmer, these all refer to different things. The first one probably refers to a class, which is a large conceptual unit in programming. The second can either refer to a variable or a function. The third is probably a variable, and the fourth is a constant.

One important thing to note is that it’s not terribly important that you follow everyone else’s convention, but just that you are consistent with your own, and let any readers know what conventions you’re using.


One thought on “Teach yourself programming, Part 2

  1. Pingback: Teach yourself programming, part 1 : Get Real

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s