Jump To

• Syntax
• Reading Docs
• Pseudocode
• Commenting
• I Want It That Way
• Eek! Errors :( Tell Me Why
• Practice Challenges

Coding can be as easy as typing exactly what you see in a book, video, or tutorial and hoping it works. This will work at first, but it’s better to have some tools to help you learn and really understand what you’re doing along the way. These tools will help you better understand what you’re doing and how things work. All of these tools are things professional programmers depend on.

Understanding Syntax

Whether you’re writing in English, Pashto, Hebrew, or a programming language they all require you to use combinations of characters, numbers, and symbols. These combinations of characters, numbers, and symbols mean something. When you were learning to read you were programming your brain to understand these combinations as different sounds. Then you used these sounds to make words. Once you could read words, you could read sentences. There are rules or syntax that tell us how sounds and words work together. Syntax tells us what the correct format is to write certain things.

In programming, syntax is used to define the correct combinations of characters, numbers, and symbols to make the code work. The syntax is different for each programming language just like it is for written and spoken languages. For every new code thing you learn, you want to make sure you look at the syntax and refer back to it if you don’t remember. If you type the wrong syntax, the computer will not understand and it will give you a SyntaxError. If you get a syntax error, look up the syntax to verify you have the right thing.

When looking up the syntax the best option is to look at the documentation. What is given in a tutorial, video, or book is probably correct, but sometimes things change or there are typos. Documentation is the go-to source for all your syntax needs.

Reading Documentation and Searching the Web

As our go-to source of information, documentation or docs as most programmers call it, is incredibly important. You can go directly to the documentation website (docs.python.org), but sometimes the website isn’t the easiest to navigate when you don’t know all the terms that are on it. Personally, I choose to go to my search engine (e.g. DuckDuckGo, Bing, Google) and type in python docs and the thing I want to look up. Most of the time, one of the first results is exactly what I need. Notice, I included the language I’m working with and the word docs.

Reading documentation can feel daunting at first. Let’s look at an example and figure out what’s what. There are several things we need to look at.

1. Syntax - the name and required symbols to use, in this case print()
2. Required things - anything inside the () without an equals sign =
3. Things Not Required - anything inside the () with an equals sign = These things may look like gibberish, but I promise, no one expects you to understand what any of this means. In the documentation there is a description of each thing in the () underneath this line of code.

Pseudocode

We all program every single day of our lives whether or not we realize it. When you get up in the morning, you plan out your day. This act of planning is creating a script or program for your day. This may not be in a computer programming language, but it is absolutely programming. It’s an informal list of steps or a to-do list. In coding, we actually do something similar to this. We call it pseudocode.

Sounds goofy, right? Why are we learning something that basically means “kinda sorta code”? Believe it or not, this is an integral step. Pseudocode is basically a to-do list. We use informal plain language to describe what we are about to code. You may think of it as an outline, plan, or to-do list.

Once you have a pseudocode outline of what you want to build, you can use the steps to help guide what you want to code. In What is Programming, there was an example about how to build a watch. That was pseudocoding. The steps were written with all the focus on how it should work and not on the programming syntax. Though, in real pseudocode, each line would be a comment instead of a bullet on a list.

If I were going to pseudocode for the watch, it would look something like this. Do know that there is no right or wrong way to pseudocode. You may choose to write it differently than someone else. That’s okay. It’s just a guide.

# Repeat steps forever and ever until end of time or battery dies

# Every 1 second up to 59, add 1 to the seconds on screen then
# Add 1 to the minutes on the screen up to 59 then
# Add 1 to the hours on the screen up to 12

Commenting

In the pseudocode watch example, every line starts with a #. Whenever you use a # you’re saying the computer should ignore what comes after it. What comes after the # is meant for humans. Typically, comments are on the line above your code or at the end of the line. It should be an explanation of the what and why of your code. Think of it as a reminder to a future you and an explanation to anyone else reading your code. Oftentimes, your pseudocode will be repurposed and used to comment your code.

You can also use comments to leave yourself to-do things with pseudocode notes.

print(“The Henna Wars”)  # output title of book
# TODO: output author of book - Adiba Jaigirdar

Note: comments are different in different languages. For example, JavaScript uses //.

I Want it That Way

One of the best and worst things in programming is the fact that we have to name things. Naming can be a lot of fun. Later on, you’ll see that I named something cat_summoning_spell. I promised I giggled when I came up with that. As fun as it can be, naming can be hard too.

Names have to be unique. They can’t be the same as anything else or your program will get confused. Imagine having a cat named “Chicken” and a pet chicken. That would quickly get confusing.

Names should also be memorable and descriptive. Using x or foo doesn’t explain what something is. Instead, you could describe what the thing is. If you’re counting stars, you could use something like star_count, star_num, or num_of_stars. Having descriptive variables will help you avoid errors.

Eek! I got an Error. What now? - Tell Me Why

If your code didn’t work, that is okay. This happens ALL the time. You have a bug and you need to debug your program. Here are the steps we want to go through. We’ll go into each of them in detail shortly. While they are in order, there is nothing saying you have to do them in this order.

1. Read the Error
2. Find the Culprit
   • Make sure the syntax is good.
   • Names match (eg variables, functions, classes, etc)
   • Comment out code
3. Ask for help
   • Rubber Duck
   • Google it
   • Actually ask someone
4. Take a Break

Understanding the Error Messages

I know, errors are scary and look like you broke something. There’s no need to worry though, it’s trying to help you. Errors tell you where the error is and what the problem might be. Let’s look at an example and figure out what’s what. There are several things we need to look at.

1. Type of error
2. Description of error
3. Line number - which line the error is on

Find the Culprit

Now that the error message has led you in the right direction, let’s look where it said the problem is. When you’re first learning to code, your most common errors will be a SyntaxError and a NameError.

You’ll get a SyntaxError when your syntax is messed up. Verify you have it right. I promise, even if you think you have it right, verify anyway. If you’re not sure, you can always look at documentation. Oftentimes, we assume we typed something right and we made a tiny mistake.

Speaking of tiny mistakes, we get NameError when names don’t match. For example, if you have something called dog_feet but you later tried to use dog_paws or dog_foot you’ll get this NameError.

If you’re having trouble finding the error, you can do what we call “commenting out code”. This means you can put a # in front of that line so the computer will ignore that line. You’ll do this with lines that work perfectly and you know aren’t the problem. This helps narrow down the offending or broken code.

Ask For Help

If the other steps didn’t help, try asking for help. There are lots of ways to do this. You can do what we call “rubber ducking” or “rubber duck debugging.” This just means that you are explaining your code and the problem (to the best of your ability) out loud to something like a rubber duck or maybe your cat. You can also do this by typing out your problem as if you were going to ask a question. Oftentimes, this will solve your problem because you’ll be reading off your code and realize what was wrong.

If explaining your code to a rubber duck, your cat, or your programmer friend hasn’t worked, try googling the problem. Typically this would mean you want to search the language you’re working with and the error. You might search something like python NameError: name 'cats' is not defined. Generally the results will lead you in the right direction. You may have to look at a few different results to get the answer you need.

Take a Break

If all else fails, take a break. Yes, seriously. Get up, walk away from your code. Take a walk, get some water, go play fetch with your dog, anything. I know you’re thinking this won’t work, but try it anyway. When you go back to your code later the problem may be glaringly obvious. It also might not be, but you’ve cleared your mind and are in a better position to find the pesky code. The goal here is to not sit there getting frustrated for a long time. Learning to code should be fun. If you find yourself getting upset with yourself, take a break.

Do you remember?

Let’s practice what we’ve learned so far. Go ahead and comment on this post with your answers. If you don't remember, no worries, you can always go back to read sections again.

Write a Pseudocode example or three

Try writing out the steps on how to do or build a real-life thing. Ideas: make a sandwich, use a TV, ride a bike, use a keyboard, or how water flows through kitchen sink plumbing