How to Read a Program
Now that you understand what a program is, and what we can do with them, let's take a look at how to read them yourself. A lot of programming is reading your own, as well as other people's, code. Rather than show you a big block of text and trying to explain it piece by piece, let's learn by doing. In this lesson we'll take a look at a program written in the same plain text style as the last lesson, and slowly convert it into something that's a little more similar to a real programming language. This will help to understand why languages are written the way they are.
Let's start super simple here:
This is fairly simple to understand as a human, but for computers, this text is pretty difficult to process. English text is very ambiguous, and things can mean more than one thing depending on context (sometimes, multiple things at the same time). Computers don't understand this context and therefore we need something that's a little more rigid. Let's draw some inspiration from something with a set of well defined rules: math.
Here, we'll convert that variable assignment—giving a value to a variable—to something that looks like a math equation:
Nice! That's much easier for a computer to read, and humans can still understand it pretty well too. Can we simplify this a little bit though? Those parenthesis look unnecessary, let's try removing those:
That's much cleaner, however, we've just created a problem here. Can you spot it? It might be a little hard to see with this example, let's try a different one:
Can you spot it now? Multi-word variable names are a little hard to read now. Is the variable named "my name"? Is it named "name" and "my" is part of something else? Let's fix this by adding some rules to naming things. Let's say that all variables must have a name that only uses letters, numbers, and a couple symbols like dash and underscore. This gives us some flexiblity in naming things, while still making it easy for a computer to tell what is and isn't part of the name. Take a look at a couple different ways we can write a variable with multiple words using our new rule. These are all ways that programmers write names in real code; in many cases there's a general consensus as to which style to use where, but for the most part, it's really up to you and whoever you're working with.
And last, but not least:
For the rest of this lesson, we'll be using camelCase for variables just for consistency.
We used math for the variable assignment, but we can also use it for... math! Let's simplify this example:
How can we turn this into a math expression? There's a couple ways to go about this, and a lot of programming languages actually offer multiple options. First, let's just reassign the variable to the new value:
This is nice, but it's a little hard to read with how much text we have here. This is such a simple operation; what if we wanted to just give it an extra special symbol since it's something we'll probably be doing super often too? That might look like:
This is another thing that's more up to you and your team's prefered style, so choose whichever one you want when writing your code.
Next let's work on transforming our if statements to fit our new look. Before we start converting our program, let's discuss a new term: blocks. What is a block? A block is simply a grouping of lines of code, that lets you pass a group of code for the computer to execute. What is this useful for? Well, you may have figured out based on the section title, but blocks are very useful for if statements (and other types of control flow statements, like while loops).
How can we represent a block of statements? One easy way is to wrap it in something. Curly braces seem like a good idea; they look pretty cool. Let's see what that looks like:
Hmm, that looks good, but that condition is a little hard to read. Let's give that a surrounding thing too—perhaps some parenthesis. And while we're at it, let's simplify that comparison to a math operator too:
Let's see how this looks with the while loop example from last time:
This is something that's much more similar to what a computer can read. While these changes aren't huge, it makes the entire block of text much easier for computers to understand. We've removed a lot of ambiguity here.
Let's do one last thing here to help the computer out; you've probably seen this before if you've seen blocks of code. Let's end all of our statements with a semicolon. This tells the computer that the instruction ends there, just like a period in a normal sentence.