Trail Index | Writing Code
At this point in the tutorial, you will be starting to write your own code. So it's time for some general suggestions...
- Use indentation to help distingushing nested blocks of code. It improves a lot the readability, gives an immediate idea of separate scopes and structures.
- Automatic indentation, provided by many source code editing programs, makes immediately evident missing braces, parentheses, semicolons. You will find that there are many styles of indentation; I personally suggest the classic Stroustrup style.
- Use an editor that provides syntax highlight by color. Especially the clear identification of comment and literal text are very helpful.
- Write comments. Any time that you write something that is not absolutely, completely self-evident, explain what you are doing.
- Write comments. Any non-trivial function should have at least a one-line explaination of what it does.
- Write comments. Any variable that has a complex meaning should have an explicative note.
- Use long names. Do not call your loop indexes
i and j, but iX and iY. Do not call the function doit(), but calculateChiSquare().
- Always initialise your variables. Avoid declaring a variable and not assigning it a value in the same line. Uninitialized variables often have a zero value, but not always, so they can cause bugs which are difficult to identify, and change if you change apparently unrelated things.
- Declare variables when necessary, not before. In C++ it is not necessary to declare all the variables at the beginning of a block (unlike plain C), so don't do it. In this way you can create the variable when you actually have a meaning value to give it - see previous point.
- Use
const. This helps you to keep a clear distinction beween constants and actual variables, and avoid incorrect/unwanted modifications; also, since const variables can only be given a value when created, this lets you follow the previous two rules. Less importantly, it also helps the compiler to optimize your code.
- Compile very often. The compiler actually checks the syntax for you; and now that computers are so fast, recompiling is usually just a moment. If it takes more than few seconds, you can keep making changes to the code while the compiler works.
- Read the errors given by the compiler. Don't just try changing stuff and see if you get it to work: those messages are there for you to read.
- Read the warnings given by the compiler: a warning usually means that something is ambiguous, and it meaning for the compiler may not be what you had in mind.
- Use an editor that integrates compling and can interpret the error messages. It will make it much easier to compile often (possibly every time you safe a file). And with just a click it will take you to the line where the compiler found the error.
- Run often. As soon as you have done one small but complete set of modifications to your code, run and test it again. If you make many changes and your program stops working, it will be much harder for you to understand which one caused the problem.
- Write test cases. When you have a complex piece of code, write another, simple code that makes automatically some minimal test on the complex one: like calling a function with well know parameters, and verify that it returns the right values - print something if it does not. In this way, when you will need to make some changes to your code, you will be able to immediately see if there is something completely wrong.
- Learn and use a Revision Control System, for example SubVersion. More on this later.
< Functions | Trail Index | Objects >
