California State University, Chico UPE

Programming Tips

  1. Start when the program is assigned. Don't wait until the night before it's due! By beginning to plan your project right away you'll better understand the project requirements, the comments and suggestions made by the professor, and the questions asked by other students. Start Now.
  2. Read the assignment all the way through. Read it again. Make sure you understand what you are supposed to do before you start. Halfway through your project, read the assignment again - all the way through - to make sure you're on the right track. When your project is finished, read the assignment once more to make sure you've met all the requirements.
  3. Plan your project. DON'T start by sitting down at a computer and typing code. Start your project by sitting down with the assignment and paper and pencil. Draw a representation of what the program looks like - the data structures, the input, the output, the relationships among different parts. Figure out what things depend on each other, which stand alone, and what data or cases you will use to test your program. Make sketches, draw pictures, or make lists - whatever works for you, but get a firm picture in your mind of what you are doing before you start to write code. Not only will this help you decide where to start, but it will serve as a guide and a reference as you proceed to write the code. As Tyson says,
    "I've been writing tree programs for 20 years. Every time I write one I draw a picture. Draw a picture of what you think the data structure should look like and then step through your insert/remove functions and modify the picture as you go. This will save you lots of time."
  4. Have a good reference book at hand. Whatever language you're using, there are many good reference books that explain concepts, give code examples, and list commonly-used libraries. It's amazing how many programmers don't want to stop to look something up because they're sure that the next compile will be correct. Five minutes looking up a principle or standard technique can save you hours of constant retrying and recompiling - and frustration!
  5. Program incrementally, that is, test the components of a system individually before attempting to test the system as a whole. When writing a larger project, write your function headers or method declarations with empty bodies and compile your project to see that the structure works. Once your program compiles, go back and write one piece at a time. Test frequently -- it's much easier to find a bug in the last 10 lines of code you've written than in the last 100 lines.
  6. Don't despair when the compiler gives you many errors. Usually an error early in the code will create other errors further on. Fix the first couple of errors that the compiler lists, then compile it again. Hint: If you find no error on the line number cited by the error message, check the line before it. The error may be as simple as missing punctuation.
  7. Learn to use a debugging program before you need it. When you need to use a debugger, you probably won't have time to stop and figure out how it works. Running through a debugger tutorial now will prepare you for using it when that mystery bug shows up the night before your program is due. To use the school Unix system debugger for C++, type "help debug" at the system prompt. If you're using Linux, check out GDB and it's graphical counterpart DDD. If you're using a Mac, try Xcode's graphical implementation of GDB.
  8. Use assert statements in your C code to find problems by catching impossible cases or crash situations. For example, you might have assert(m_head != NULL) in your code somewhere before an operation that might segfault if m_head is null. If it is the case that m_head == NULL, then an error will be printed with the filename and line number of the code where the assert was hit. As Tyson says:
    "Use lots of assert statements. When I program, I put assert statements everywhere. They save me lots of time. A logic error that would take hours to find using a debugger or cout statements, is often found right away by an assert statement."
  9. Use print or cout statements in your code to help isolate a problem location. Sometimes it's useful to know the value of a variable before and after a calculation; when a program is entering into, inside of, or returning from a function or method; or to confirm that a pointer points to what you expect it to. However, if you learn a debugger, you will not need cout statements as you will be able to manually step through your code and use breakpoints to focus on certain parts, checking the value of variables and understanding where your program is going wrong.
  10. Get help when you need it. UPE tutors are available throughout the week, check our tutoring schedule.