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