Learning to Program- Two Main Types of Errors

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:)
Patrick.

E-Book on Programming and Logic

I’m planning on writing an e-book about Programming and Logic. Right now, I have a basic Table of Contents set up, and I want to get some feedback from people who are learning to use Pseudocode and Flowcharting.

Some questions that I have for you are these:

1. Which do you think is harder, creating flowcharts or pseudocode?
2. Would you prefer to see a) more flowcharting examples, b) more pseudocode examples, or c) an equal share of each?
3. Which aspects of logic are you struggling with (for example but definitely NOT limited to: variables, arrays, looping, decisions, methods, classes, objects, or data types)?

Please post in the comments section, and I’ll be more than happy to frame the book along the requests. Also if there are other subjects that I haven’t covered in the questions, please post those as well.

At some point, I’ll be posting the table of contents for opinions on things like the chapter names, the order that I’m presenting things, and the structure of the book overall.

Thanks, and have a great weekend. 🙂
Patrick.

An important note to consider in Programming and Development

When you take a course in Programming or Logic, you’re taught a certain way of doing everything. It varies by the language, but you’re taught to indent your code a specific amount of space, use certain namingConventions for variables, put braces and other symbols in a specific way, and other things.

The problem with this is the industry and your future (or current) employers may not follow these conventions. And your instructors (and books) won’t point this out to you. So you have to find out what the current industry (and employer) standards are, and follow those. In short, you need to overcome and adapt to the environment that you’re thrown into.

It really becomes apparent if you’re employed by a company to code, and you also code for other projects on the side. For example if you’re a C/C++ coder, your employer may follow the industry standards (or not). And if you decide to write code for the Linux kernel. The kernel has it’s own set of standards–ranging from how to indent and how far to indent, to when to put the {}’s on the same line or a new line. They don’t necessarily follow the industry standard.

Again, your instructors and books won’t talk about this. Their goal is to show you everything in one easy to learn fashion. The industry expects you to adapt what you’ve learned to their version of “reality”. So if you’re taking programming courses now (or plan to), remember that what you learn is just the foundation for what you’ll do. The foundation will look the same regardless, but what you build on that is up to the needs/wants of whoever you’re building it for.

Have a great day:)
Patrick.

Learn to Program – Stage 7 (Maintenance)

Stage 7 is probably the strangest stage.  Why do I say this?  Because maintenance means a lot of things.  If the program is decently coded and no bugs are found, then the maintenance stage basically means leaving it sit.  However, if bugs are found, then you will be going back through Stages 5 and 6 to correct them.  And if more (or new) features are requested, then you may have to go back through all of the stages to complete the task.

At some point, maintenance actually becomes a whole new concept with it’s 7 stages.  Although most of the hard work will be done already, so it won’t be as involved as the original coding process.  One thing that you can do to ensure the ease of maintenance is to plan for the future of the program when you are designing it. 

The concept of looking three steps ahead applies in chess and coding.  As you’re designing the program in the early stages, consider the other things that you would throw into the program (if you could).  Design the code so you can incorporate them into the program—if someone requests it. 

But don’t go overboard with this.  You don’t need (or want) to create empty classes for these items.  But you want to code the program in such a way that you can add classes (and interfaces to those classes) with minimal rewriting.  As you are creating your classes, decide if any of them could be easily tweaked to add features.  If so, then design them in such a way that you can add those features.

Even now, when the idea of code optimization isn’t the “in thing” (because of large amounts of memory and CPU power), you should code in such a way that future versions will not increase the footprint dramatically.  I would suggest coding for optimization anyhow.

Coding for optimization is similar to how people coded in the 80’s and 90’s.  There was very little memory available to them, and the CPU’s weren’t as powerful (or capable) as they are now.  So, the programmer optimized the code in such a way that it accomplished a lot without requiring a lot to do it.  In short, it means that if you can code something to use 1MB of memory, why would you code it in such a way that it uses 3MB?

Have a great day:)
Patrick.

Learn to Program—Stage 6 (Documentation)

This is probably the easiest stage—or should be.  You should be creating documentation as you go through the previous stages (from your IPO and PAC charts to the flowcharts to pseudocode and UML diagrams and finally the code itself and results of testing).  Stage 6 is writing up the final documentation explaining what you were trying to accomplish and how you did it.  It should organize the documents from the other stages.

This is also the stage that most people hate to do.  The thing is when someone else has to do Stage 7 (Maintenance) or someone wants to upgrade your programs to solve a new problem, this documentation will make their (or your) lives a million times easier.  Documentation includes the comments inside of your code—but should not be limited to that.

You should also include any problems that you had and how you overcame them (or the workarounds that you put in place until you can overcome the problems).  It should include features that you started, but could not implement—along with information on how far into the feature you were able to delve.  Included in the problems are other experiences that you had.  Even if they aren’t problems, if they are something that another coder may find useful (or you may find useful down the road), document them.

If you’ve been keeping accurate documents along the way, this should be the easiest step for you.  If you haven’t been keeping accurate documentation, then you have just entered Dante’s fifth plane of Hell.  Either way, this will ease the transition into Stage 7.

And with that, we will cover Stage 7 (Maintenance).

Have a great day:)
Patrick.

Learn To Program—Stage 5 Testing

As I mentioned in my Stages of Programming post, this stage typically runs concurrently with Stage 4.  As you create an executable version of the program, you’ll have people test it out.  They’re looking for bugs, making suggestions for features that they want, and testing out the overall quality of the program.

Even a perfectly written program with all of the features is worthless, if it doesn’t do what the client/customer/end-user wants or needs.  So one measure of quality is whether or not your testers want to use your program to accomplish the task.  Another is the fact that the program runs, and they aren’t able to crash it (or get unexpected results). 

If you’re programming for a limited customer (such as a corporation or a person), then you will have a small group of their employees testing your program.  If possible, you will want to be on-site, although it’s possible to do it remotely. 

If you’re programming for a larger audience (such as an Operating System or an application that the public will use) then you’ll want to get as large of a test-base as possible.  For example, Microsoft has tens or hundreds of thousands of testers in their private betas—and countless more in the public betas, for their Windows Operating System releases.  In the event that you are doing a public application (and a public beta) you will probably want to assemble a team for coding and triaging bug reports.

Even if your program is a simple upgrade to an existing program, you need testers.  If you don’t test before releasing the upgrade, you could potentially break something that the users need, introduce logic (run-time) errors, corrupt data, or countless other problems.  Any way you look at it, if you cost your customer money because of shoddy code, you’ll cost yourself more money.

Depending on the complexity of the program, your testing could be a few days to a year or more.  And you could release one build or multiple builds.  But it all needs to be planned in to the project.  And you shouldn’t skimp on time, money, or resources for the testing.

For more information about the stages of testing, please look at this post.

Next we will cover Stage 6 (Documentation).

Have a great day:)
Patrick.

Learn to Program – (Stage 4) Coding

Ok so we’ve covered the first three stages (defining the “problem” with IPO charts and PAC charts, flowcharting the program, and pseudocode and/or UML diagrams for the program).  Now we’re on to actually coding the program in the required language.  I won’t teach you the syntax of the language or any particular languages here.  My intent is to give you some general guidelines to use when coding.

  1. One of the things that I’ve learned in Java is to create a test application, the required classes, and the actual application. What this means is the test application will have specific data in it to make sure the methods and classes work as expected.  You can delete the test application afterwards or comment it out.
  2. Code the entire program to a point where it will run, then compile it.  This means, if you’re using the test application, you code it and the classes and compile.  Otherwise, you code the main application and classes then compile.
  3. If the compiler has errors, typically it will say the error is at the last good line.  So, if it says the error is on line 4, then you want to start looking around line 5 (because if it can’t compile the line, it doesn’t know it existed).  Some compilers will list all of the errors that it finds, where others will stop at the first error.
  4. If your program has a bunch of errors, fix the first one and compile again.  Don’t fix all of them at once.  This sounds time-consuming and illogical, but here’s the reasoning.  Sometimes the other errors are only because of the first one.  So, if you fix it and recompile, they may go away.  However, if you fix all of them, you may introduce new errors.
  5. Just because your program compiles doesn’t mean it’s right.  Run it and try to break it.  If it’s a program dealing with money, for example, try negative numbers and see what happens.  In my Java class, we had to code a basic bank account program, where the only requirement to validate was that the balance was greater than the withdrawal amounts.  I threw a negative in for the deposit amount and got some fun results.  Technically, we should have validated that as well.
  6. If you run into any unusual errors or situations, make a note of them. You never know when they’ll pop up again, so it’s good to have some idea of how to work your way out of them.  This same rule applies for anything that you think may make a good class or library.  Make note of the code used, and compare it to future programs.  if you’re reusing the same code with different variables (of the same type), create a library and link to that instead of reinventing the wheel.
  7. If at all possible, have other people use your application and break it for you.  You can’t come up with all of the possible ways, but if you have five or ten people playing around with it, they’ll come up with more.  Depending on the scope of the users (meaning how many will be using it in the end), you may want more or less people “beta testing” it.
  8. Most importantly (especially if you work on multiple projects at once) keep your things organized.  Slot out a specific time for each project, and when the time is up, move any papers or physical parts (discs, screenshots that you printed out, etc) to a file folder. Don’t leave it all on your desk—even in organized piles.  Eventually, you WILL get them mixed up. 

    This last tip is good for everything.  It just makes it easier for you to pick up where you left off.  Along that line, make sure that you leave yourself (or someone else) adequate notes about where you’re at in the project.  This way, if you end up shelving it for a week or two, or someone else gets assigned to it, restarting is just like continuing on.

  9. The last tip that I can give you is when in doubt, look it up in the documentation.  Every language has documentation and “API” lists to help you integrate their pre-defined code into your program.  Use it.  You’ll be surprised at what you learn.

Tomorrow, on to Stage 5.

Have a great day:)

Patrick.

Learn To Program—Stage 3.5 (UML Diagrams)

In my Java course, we began working with UML Diagrams.  UML is an acronym for Unified Markup Language.  The easiest way to explain this is, it is a blend of objects, classes, pseudocode and flowcharts—all wrapped up into one.  I’m not sure whether other languages support these diagrams, but I would imagine that you can still use them.

First a little explanation.  Objects are similar to objects in real life.  They have attributes (variables) like real-life objects, and they have actions that you can do with them (operations or methods) like real-life objects.  Classes are objects.

Here’s an example.  A ball is an object.  It has attributes: size, shape, color, texture, contents (air, water, foam, etc), and graphics.  You have operations that can be done with a ball:  throw, catch, hold, bounce, inflate, and deflate.

A class is like the ball.  It has attributes (the variables that make the class function), and operations (the methods inside which allow you to access and use the variables).

There are two main types of classes.  Superclass and subclass.  A superclass is a container for all of the common elements in it’s subclasses. And a subclass is the individual elements for it’s specific need.

The example of this that we’re using in Java is a ticket system.  The superclass is the Tickets class, and the subclasses are how the tickets are delivered (will-call, e-delivery, or mailed to you (Printed)).  The common elements among all of the subclasses are “event name, location, date, time, cost and number of tickets.”  The individual elements are “e-mail address” (e-delivery), “booth location” (will-call), and “mailing address” (Printed).

Then you get into inheritance.  Inheritance means that the subclass “inherits” or uses the common elements from the superclass—along with it’s individual elements (without having to create a new instance of the superclass).  In UML Diagrams, inheritance is shown by an arrow connecting the subclass to the superclass, with the direction going towards the superclass.

The reason that I’m bringing this up, without going in depth about it is this:  In Java, at least, if you create a UML diagram, you’re able to generate code from it automatically.  What this will do is, it will create all of the variables for you, and create the names of the operations.  You will still have to code the operations themselves, and tweak them a little to make them work.  But, the UML will at least create the backbone for you.  And it will simplify the inheritance issues for you (by automatically adding the extends superclass to the subclasses).

If you’re coding in Java, and wish to learn how to use the UML diagrams, there is a tutorial at http://netbeans.org/kb/docs/uml/class-diagram.html. Beware it’s intended for Netbeans 6.5 and has not been updated to Netbeans 6.7 or later. And in Netbeans 6.8, you have to use a third-party plugin to do UML diagrams.  So, there are variations in how they say to do something, and how you’ll do it (minor things like left-clicking instead of right-clicking and Create … instead of Insert…).  Also note that when you generate the code, you have to click outside of the Netbeans window and back for it to show up in your target project.

One last thing to note about UML diagrams (in Netbeans at least).  If you have code already, you can reverse-engineer it into it’s UML Diagrams using the plugin.

Now, I’ve finally covered all of the ways to get to coding.  Tomorrow, we’ll start talking in general about the actual coding. At the bottom of this post, I will include a picture of the UML Diagram from the tutorial.

Have a great day:)
Patrick.

UMLDiagram

Learn to Program – Stage 3: Pseudocode—Methods

In today’s post I will discuss methods and classes, and describe how to use them in pseudocode.  Methods and classes are inherently the same thing, but there are differences between them.  Especially when you get to actual programming languages.

A method used to be called a subroutine or a procedure (in Pascal or Delphi, it may still be called this).  It can be thought of as a break from the main program to do a specific task.  Imagine if you will an assembly line that looks like this:

statiion 1:  Put the outside of the product together (if it has multiple parts)
station 2:  Put the inside parts into the product and anchor them.
station 3:  hooks everything up to make the product work (wires, boards, etc).
station 4: tests the product to see if it works.
station 5: packs the item.

Now, imagine that after the product is tested, you have to let a QA inspector check it.  Instead of them being in the line, you have to turn around and hand the product to them.  Then they hand it back, and you send it down to the packer in station 5.

This is the same premise as what a method does.  The main program handles the other things, and the method or class handles the specialty items.

So, what is a class?  A class is a special type of method.  In fact, it is a group of methods that all interact with the same type of data, and can be reused in more than one program without having to recode them.

In Pseudocode, you will typically start your methods after the STOP command in the main portion of your program.  If you’re creating a new class, then you will have it on a separate page—along with it’s methods.  And you will declare some type of variable with the class name for it’s type.

Methods:

START
      num miles
      num gallons
      num milesPerGallon
      print “Enter the miles”
      input miles
      print “Enter the gallons used”
      input gallons
      milesPerGallon = miles / gallons
      print “The miles Per Gallon are:  “, milesPerGallon
      TrivialFacts()
STOP

void TrivialFacts()
      print “This is a subroutine or a method.  We’ll now return you to the main program.”
return

(this pseudocode is loosely based upon an exercise in the book Programming Logic and Design, Introductory by Joyce Farrell.(pg 129). (Please note that this link is to the Amazon.com website, through my Affiliate account.)

Classes:

START
      num miles
      num gallons
      num milesPerGallon
      OtherClass differentClass
      print “Enter the miles: “
      input miles
      print “Enter the Gallons: “
      input gallons
      milesPerGallon = miles / gallons
      print “Your Miles per Gallon are:  “, milesPerGallon
      differentClass.TrivialFacts()
STOP

class OtherClass()
public TrivialFacts()
     print “You are now in a method from a different class”
return
endclass

I added the endclass as something to show the end of the class.  In a programming language such as Java, you would create the class with the name Other Class, and where I had “OtherClass differentClass”, you would put:

“OtherClass differentClass = new OtherClass” (other languages may do this differently).

With this, we are ready to move on to Stage 4 in Learning to Program.  Once again, if you have any questions or want me to go over something in more detail, please leave a comment or send me an e-mail to sales at patscomputerservices dot com (at=@ dot=.).

Have a great day:)
Patrick.

Learn to Program – Stage 3 Psuedocode (Arrays)

In today’s post, I want to discuss arrays and give you a little insight into how to use them in pseudocode.

Arrays:

Arrays are variables.  You can look at arrays in quite a few different ways.  You can look at them as a table (like an Excel Spreadsheet or a tic-tac-toe board), or you can look at them like multiple copies of the same variable.  Either way, hopefully a graphical representation will help.

For the representation, I’m going to use two different variable names.  cupOfCoffee and graphCoordinates.  cupOfCoffee will be a one-dimensional array, and graphCoordinates will be a two-dimensional array.

cupOfCoffee1 = 0
cupOfCoffee2 = 0
cupOfCoffee3 = 0
cupOfCoffee4 = 0

is the same as saying cupOfCoffee[4] = 0. 

Now for the two-dimensional array (this holds true for multi-dimensional arrays too—just more sets of numbers):

graphCoordinates[0,0] = 0
graphCoordinates[0,1] = 0
graphCoordinates[1,0] = 0
graphCoordinates[1,1] = 0

is the same as graphCoordinates[2][2] = 0.  And it would look like this, if you printed it out:

00
00

The important thing to remember with arrays is that the computer considers 0 to be the starting number of an index.

Another way to look at the two-dimensional array is like this:

graphCoordinates[0,0] = 1
graphCoordinates[0,1] = 2
graphCoordinates[1,0] = 3
graphCoordinates[1,1] = 4

and would be represented like this graphCoordinates[2][2] = {1,2,3,4} (this is also how you would list one-dimensional arrays that have values other than 0).  If you printed the array out, it would look like this:

12
34

Arrays are used to hold groups of related data.  Such as if you have four cups of coffee, you could put the total ounces that are in each cup.  Then as you drink one of the cups (it doesn’t have to be the first or last one), you can change the number to reflect the new level—without having to change any other cup.

In pseudocode, you will declare an array like you declare any other variable.

For a numeric array, it would be

num arrayname[index] = 0 (or {listed values}).

For a String, it would be

String arrayname[index] = “” (or {list of values in “’s separated by a comma}).

The other types will be the same.  The “index” is the total number of values you want to store.

Putting values into an array can be done using a FOR statement, an input statement, or even with case statements.  I will demonstrate with FOR statements here:

num MAXSIZE= 4
num array[MAXSIZE]= 0
FOR i = 0 TO MAXSIZE-1
     array[i] = i
ENDFOR

The reason I have the MAXSIZE-1 in there is because you may have four spaces in the array, but the computer has indexed them as 0, 1, 2, 3 (where you’re thinking 1,2,3,4).  So remember when dealing with arrays, you have to account for that difference between “Human indexing” and “Computer Indexing”.

In the FOR Statement above, if you changed the line array[i] = i to PRINT array[i], it would print the array.

In my next post, I will describe methods and how to use them in Pseudocode.  Thank you for reading these posts and if there is anything that you want me to describe in more detail, please leave me a comment or send me an e-mail to sales at patscomputerservices dot com (at=@ dot=.).

Have a great day:)
Patrick.