Start learning with our library of video tutorials taught by experts. Get started
Viewers: in countries Watching now:
Finally, the course compares how code is written in several different languages, the libraries and frameworks that have grown around them, and the reasons to choose each one.
When you're new to programming, it's usually difficult to write even a single line of code that works correctly. Programming languages are so specific and it's very easy to use the wrong case, to use a colon instead of a semicolon, to miss a closing quote, to use the wrong operator, the wrong name. when you write programs that aren't trivial, once you get beyond hello, world, it's really tough to write more than a few instructions without tripping up over your own logic. So yes, you expect your code to work and it's natural to get frustrated when it doesn't, but here's the thing that experienced programmers know that non-programmers don't.
We don't expect our code to work anymore. Seriously, we don't ever expect to just write a program that works correctly the first time through. Our code still breaks all the time. You see programs aren't just written. They are edited into existence, they are built slowly, piece by piece and every programmer expects to spend far more time debugging their code than actually writing their code. We write a few lines, we check it, we fix it, we then write a few more, we check them, we go back and fix the first ones we just broke, and we keep repeating the process.
The thing is yes, it is easy to make mistakes, so don't worry about making mistakes. Go make a thousand of them, and then fix them, then make a few more. Now, we're going to debug our code. We're going to find out what went wrong and we're going to fix it. I am talking here of everything from just getting your program to run in the first place to six months down the road, you thought it was working fine but you're getting some odd behavior. So how do we start to think about this? When we have errors in our code, they really break down into two main categories.
The first and most obvious are syntax errors and then we also have logic errors. So let's talk about the difference. The most obvious kind of problem is with syntax. Something is wrong with the actual format of what we wrote. You spelled a keyword with the wrong case letter, you used a colon instead of a semicolon, you forgot to close a quote on a string, and if it's that easy to do it on the simplest statement there is, just think about what it's like when you've got a lot more code, thousands of lines of this.
Even experienced programmers will from time to time just have to go through letter by letter figuring out, what did I miss here? It's quite common to count the opening and closing curly braces to make sure that they match up. Now, one of the benefits of using programmer's text editors and having things like syntax highlighting is it can point some of these things out. Let's say I am working in an editor and I know that green means a comment. So if I see a big block of code like this, I can immediately think, hang on, there's a problem here, and what I can see is I accidentally opened a multi-line comment, making everything after this an actual comment, whereas what I wanted was a single line comment that looks like this.
Then we have logic issues. These are really the main problems for any program and this is where the code you wrote is correct in syntax and if you're working in a compiled language, it will even compile, but there is a flaw in the logic. The fencepost error that we talked about early in the course is one small micro-example of a logic error. You've got a loop that just isn't going round enough times. It's one time too many or one time too few. Another example would be creating a function and that might have a lot of code in it but somewhere in the middle, you've got a return statement.
Well the problem is, if you hit a return statement and a function, you'll immediately jump back out of the function into whoever called it, which means any lines after the return statement would never be executed. And these are just three very obvious examples of logic errors. The problem with most of them is that they can be extremely difficult to find. There are some logic errors that even fall into their own category like problems with arithmetic. What do we mean by this? These are also correct in syntax but they just don't make sense.
But in many other programming languages, the line that tries to divide by 0 will cause your program to crash completely. And yes, these are just a few examples of the things that can go wrong. The logic errors will be the most significant problem you'll ever have as a programmer. But in any debugging situation, the first step is always reproduce the problem. Does the same error occur the same way each time? Hopefully it does, because that's going to make it easier to find. After this, we need to figure out where in our code the problem actually is and that can be more difficult than it seems.
For that, we need to figure out if our program is actually running the way we think it is.
There are currently no FAQs about Foundations of Programming: Fundamentals.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.