Logout

Criterion P - Programming

Trouble-shooting & Programming Approaches

 

Git Hub

As you get into your programming stage, one option you might consider, to help keep backup copies of your program and to track changes, is to use Git Hub (github.com).

 

Commenting Your Code

A common weakness of novice programmers is the amount of commenting they do as the program. But, A. You absolutely should, and B. You will eventually have to as part of this project. A big part of Criterion D is your commenting; it is the main thing that will make your program "extensible" - i.e. someone will be able to look at your program later on, understand it, and extend its functionality.

If you end up leaving a lot of your commenting until later, it will be a Royal Pain, since what you did is no longer fresh in your memory. Over the years I have seen too many situations where the student keeps on putting off doing, or catching up with their commenting, and in the end, in the rush to do other final stages things, they just can't, and end up losing 2 or 3 or even 4 very straight-forward points out of the 35.

 

Structures to Use

You really should be using either ArrayList or LinkedList, rather than just arrays. So use LinkedList if you are able to apply either a stack or a queue, and an ArrayList for everything else.

You should also look for opportunities to use polymorphism, with both overloaded constructors and overriding, and inheritance, even if pretty simple.

Here's an image to remind you how arrayLists, tables, and files should all interact. (The point being that the arrayList etc. is the central structure for holding and working with the data.)

 

Troubleshooting Hints

- When errors are reported in the Output window, click on the top blue link to see where the error occurred.

- At the first sign of a "spinning wheels" situation, get up, go for a walk/get a snack etc. and then come back and look at it again.

- If/when you do start spinning your wheels in earnest, either seek help, or take a big long break.

- And as mentioned in the Responsibilities rubric, you should never go more than half an hour trying to crack a very difficult problem before seeking help from me or another student. Or just stop, and look at it another day.

- Use souts liberally, to check the values of various variables at different stages of algorithms.

- Don't test with any errors (red rectangles) still showing, even if you don't think they affect what you are presently testing. Fix all errors before running, just in case.

- If spinning your wheels, besides going for a walk, just try a different approach, even if it doesn't seem like the best one; by looking at the problem differently, you might spot the thing you've missed.

- Working with GUI objects, and using their methods, remember that those methods often return Objects, which you may have to change into Strings with + "".

- Some major issues can occur because there are two problems happening at the same time. So fixing even a minor problem, that you don't think is the big deal, may very well get you one step closer to solving a bigger problem. The point being: even the smallest of errors, you should always fix as soon as you can.