How to Write Correct Programs Faster

If you talk to some students that took ECE 264, they will likely tell you the following:

• The programming assignments can take a lot of time.
• You will learn many new concepts and programming skills.
• You really need to know Linux well. You can use ssh to enter an ECN computer. Manging tools on your own computer may take a lot of time.
• If you do not use a debugger (and printing lots of "debugging messages"), you will likely spend a lot of time debugging your programs.
• You will understand the "Murphy's law" fully: anything that can go wrong will go wrong. Moreover, things will go wrong during grading.

ECE 264 is a "bridge" course, helping you transition from writing small "toy" programs (tens of lines) to slightly larger programs (hundreds of lines).  You need to change how to write programs. What works for writing twenty-line programs would not work when your program has two hundred lines. Here are some suggestions to help you write correct programs faster. The emphasis is correctness.

Learn touch typing (i.e. typing without looking at the keyboard). There are many on-line training programs. Yes, the training is boring but touch typing is one of the basic skills in computing. If you can type fast, you spend less time moving your program from your head to a computer.

Attend lectures

The instructors will tell you common mistakes. You will not learn and avoid the mistakes by reading any book. All books tell you what is right; they do not tell you what is wrong and the reason. As a result, you are likely to make those common mistakes.

Think, Plan, Code, and Read before Testing

If you have the habit "coding-testing-debugging", it is time to change.

This is what you should do to write correct programs faster:

1. read the specification and understand the requirements
2. think about your solution
3. write down solution (on paper)
4. create some simple test cases
5. plan your program
6. write a small piece of code (one function at a time), no longer than 30 lines
7. read your code line by line and run the test cases in your head
8. test the program on computer by using the simple test cases
9. go to step 6 until all everything in your plan (step 5) is implemented
10. use more complex test cases

The sooner you start writing code, the longer it will take. Why? When you write a twenty-line "toy" program, it is like building a simple bookshelf with four boards. Cut the boards, hammer nails, and you are done. In ECE264, you don't write toy programs any more. You are constructing a five-story building (not a skyscraper yet). You need a plan. You cannot rely on luck. You need to ensure that the foundation is solid. If you rush, the building will collapse and you need to start over. You should completely change the minset "program and then debug." You have to be careful and make your program correct the first time.

In ECE264, you will find "The sooner you start coding, the longer it takes."  You must have a plan if you want to write correct programs faster.

Array Indexes

Invalid indexes for array. In C, if an array has n elements, valid indexes are between 0 and n - 1 inclusively. Many students use 1 to n. The problem of this mistake is that the program's behavior is unpredictable. The Murphy's law says that your program will "work" when you test it and will fail during grading. How can you prevent this mistake? Always use

                for (index = 0; index < n; index ++)

Initialize Variables or Pointers

If you do not initialize a variable or a pointer, the value is garbage, not zero. As a result, your program's behavior is unpredictable. The Murphy's law will make your program "work" when you test it and will fail during grading. Some students think initialization will slow down programs. Well, that may be true but the difference would be nanoseconds.

Touch Typing

If you look at the keyboard during typing, you will not look at the screen. As a result, you do not know what is actually entered into the computer. You should learn touch typing so that your watch computer screen, not keyboard. There are many on-line free training programs.  You can type much faster if you spend three to five hours through those training programs. "I don't have time to do that." The reason you don't have time is that you spend too much time typing. Spend five hours learning touch typing and save hundreds of hours.

Debugger (GDB)

If your only "tool" for debugging is to print messages on screen, it is time to learn a debugger.  Debugging messages will not tell you what is in the call stack. It will not tell you which line causes segmentation fault. You have to modify the program for inserting debugging messages. You may not insert messages at the right places. You need to learn a debugger. "I don't have time to learn a debugger." The reason you don't have time is that you spend too much time modifying your program for inserting debugging messages. Spend half an hour learning a debugger and save hundreds of hours.

Valgrind in Linux

You should be very careful in each line you type. However, mistakes may still occur. It is difficult to correct mistakes if you do not know their existence. You have to abandon the belief that "If my program runs and produces correct output, my program must be correct."  In many cases, you are lucky. For example, your program should crash due to an invalid index. However, the Murphy law says that your program will "work" when you test it and will crash during grading. You should use valgrind to check.  It tells you many hidden problems such as memory leaks or invalid indexes.  Running valgrind is like performing "pre-flight" checking.  Every pilot has to check a plane before taking off. You should always run valgrind before submission.