- Learning to Program—The stages of programming
- Learning to Program – Some Terms You Should Understand
- Learning to Program – IPO Charts (Stage 1)
- Learn to Program- Flowcharting (Stage 2)
- Learning to Program – Flowcharting (Stage 2). — Decisions and Loops
- Learning to Program—Flowcharting (Stage 2) – Case Statements
- Learning to Program (Stage 2)—Flowcharting – Methods and Classes
- Learning to Program – Structure and Spaghetti Code
- Learning to Program – Pseudocode (Stage 3) an overview
- Learning to Program – Stage 3 Pseudocode commands and reserved words
- Learning to Program—Stage 3 Pseudocode examples Part 1
- Learning to Program – Stage 3 Psuedocode (Arrays)
- Learning to Program – Stage 3: Pseudocode—Methods
- Learning To Program—Stage 3.5 (UML Diagrams)
- Learning to Program – (Stage 4) Coding
- Learning To Program—Stage 5 Testing
- Learning to Program—Stage 6 (Documentation)
- Learning to Program – Stage 7 (Maintenance)
- Learning to Program—Random Thoughts with a Theme
- Learning to Program- Two Main Types of Errors
- Learning to Program – Integrated Development Environments (IDE’s)
- Learning to Program
In programming, you’ll encounter a lot of different errors. Syntax errors, functional errors, configuration errors, and more. All of the errors can be classified as two main types though: compiler (or compilation) errors and run-time errors.
Compilation errors are the syntax errors and other problems encountered while creating the program. They are found and fixed before the program is released to the customer (end-user or the public, as the case may be). These won’t impact the customer, because you’ll fix them before you release. Otherwise, your program won’t work.
Run-time errors are errors that involve the logic or function of the program. Some of them will happen before release, and some will happen after. The goal is to make sure most of them happen before release, but nothing is perfect.
One example of a run-time error is in a program that I’ve been developing. Essentially the program is an updater for an IP Address. The error is that once I enable “Automatic updating”, I can’t disable it (or change the time-frame for the updates). It’s a functional error, because while the logic is sound (making sure you can automatically update and set the interval), the way it’s implemented doesn’t work.
If you have run-time errors after the program is released, you’ll be informed via bugs or security notifications (depending on the type of error). Some of the errors are features that don’t work properly, features that people want, security vulnerabilities, or other problems.
The point here is two-fold. First and foremost, you’re going to run into compilation errors and run-time errors. If you don’t, then the program was either fairly simple, or you didn’t write it. Now, let me clarify that occasionally you’ll write a complex program without any errors–but it’s rare.
Secondly, your goal is to minimize all of the errors as much as possible. Your goal is 100% perfect code. Your reality should be somewhere between 92% and 98% perfect code. Don’t release unless your compilation errors are 2% or lower, and your run-time errors are 5% or lower.
And test for every possible scenario that you can think of. Even the ones that are highly improbable. Because, the more people who use the program, the more probable one of those scenarios will happen. And have others test for everything they can think of also. That’s how the “professionals” do it.
Have a great day:)