Ten Things To Know Before You Write Any Programs

Ten Tips to Get Started

1) Give variables meaningful names. For example don't name the variable keeping track of your first linear equation a, call it linEqA. This may seem like a pain, but will result in quicker debugging.

On this note, remember that names are case-sensitive. If you call a variable a and then try to change A's value, you will actually be creating a new variable. This is a very common source of error that can be hard to spot. You can always check all the variables you have currently defined by typing who or whos (this will also give sizes and type). This should make any case issues pretty obvious.

2) Ensure the logic flows naturally. Make sure you know what each part of the program is doing and make sure its performing actions in a sensible order. Some programs don't enforce a strict order, but MATLAB does! Dr. Sutherland's lecture notes are often very useful for this task. Look for the topic's 'algorithm' or sequential steps in the slides. It will only save time in the long run if you have a clear idea of the program's goals before you start coding.

3) Write in chunks and test at frequent intervals. It's far easier to decode 2 lines than 20. If you've already broken your task into steps, you can check to make sure each one is working. For example, declare all your variables. Run the program and make sure all the values are typed in correctly. Then add one component, say a for loop. Watch the loop run for maybe 5 iterations (later you can change to as many iterations as you need and suppress the output using a semicolon at the end of the line). Make sure it's behaving as expected, etc.

You can also decompose your program for easy readability and debugging. If you identify tasks 1, 2 and 3 which work relatively independently, write them in three separate ‘helper’ m-files and then call them in your main program. Of course, 1 should really be something like setUpInitVars and 2 should be solveLinEqs and 3 should be plotNicely! Then when you are writing your main program you will call these three function and you (and the TA grading your homework) will know exactly what you’re trying to do.

4) Don't copy and paste. Clearly you shouldn't copy and paste other's work, but copying your own code can be just as bad of an idea. If you find yourself declaring the same variable over and over again, for say parts a, b and c of a problem, consider declaring them in one m-file (see tip 3). You can then call this at the very beginning of the programs for a, b and c. This ensures that you will be consistent and that you'll save a lot of time when you realize you need to change an initial variable.

5) Start all programs by clearing your variables and command window. The top of each m-file should begin with clear all, clf, and clc. This will ensure you are starting with a blank slate. Sometimes hard-to-find-errors will occur because MATLAB is remembering the definition of a variable you have long since forgotten about. It’s also good practice to begin with an opening comment about what you intend the program to do. On that note:

6) Comment (by using % at the start of the comment)! Commenting helps for a couple of reasons. It ensures that you are focusing on what each part of your program should be doing. It will also help when you go back to finish up or look at an old program. You may know exactly what you're doing at the moment, but keep in mind that you may want to look at this code again in 2 days or 2 years.

7) Use neat formatting. Ctrl A followed by Ctrl I will highlight your entire program and then align it nicely. In general it's standard practice to indent the inside of loops and use a fair bit of white space for easier read through. MATLAB doesn't care about spaces or empty lines, so you should separate sections with a few lines of white space. You can also leave space in equations for easier read through (3 * a + b is often nicer to look at than 3*a+b). Everything's electronic, so don't worry about killing trees.

8) Be careful not to leave out * or .. MATLAB doesn't do implied multiplication, as in 3(b+a). You have to explicitly tell it you want to multiply two things - 3 * (b + a). Another common problem occurs when matrix arithmetic is done instead of elemental math. If you want to follow the rules of linear algebra, leave out the dot. If, as more commonly occurs, you want to do an element by element operation use a dot/period (.). For example, A*B multiplies two matrices together following the standard method defined in your Linear Algebra class. A.*B tells MATLAB to multiply each element in A with the corresponding element in B (e.g. A11 * B11, A12 * B12...).

9) Let MATLAB help you. Try to make sense of any error messages. This is a very valuable tool, so ask if you don't understand what all the red text is trying to tell you.

10) If you've followed 1-9 and things will still aren't working, don't spend more than 45 minutes trying to get your program to work without making any progress. At some point perseverance turns into obstinance. That being said, do try and use all your resources before seeking help. Look through the notes. Go to other sections of the wiki. Try MATLAB's help <function of interest>. Google your question. Go to MATLAB's website: mathworks.com.

TL;DR Know what you want your program to do and then write it slowly in a logical order with lots of testing as you go. Always err on the side of writing more comments, giving variables more descriptive names, and leaving more white space so you can clearly see what everything should be doing today and next week. Remember to let Matlab help you by paying attention to error messages and using commands like who and help.