Some advice to computer programming
Computer is more and more important nowadays. Even if you're not doing work directly related to computers, it's still useful to have the tool ready. It speeds up a lot of things. Before you dig into programming, these are a few general things that I wish I had known when I started learning how to program, and I want to share with you.
The real challenge (and fun) of programming is to think about how to distribute resources between different parts, and how to "speak" an algorithm in a comprehensive way to both computers and humans.
Efficient programming is an interplay between development cost, execution cost (how long the program runs) and maintainance cost. It's not good for any of them to be too time-consuming, especially maintainance, which is usually overlooked in classes that teach you how to program. For new programmers, they will probably be struggling with making the code work. But once you go past this barrier, usually what you will find is a lot of little tricks that are either cool-looking or those that make execution cost a bit lower, while leaving the code hard to read. This is one big trap for inexperienced programmers. Unless you are writing programs that have a tight time budget or memory budget, it's usually a good idea to exchange a little bit of execution efficiency for readability and easiness for maintainace. Take C++ for example, there is this code fragment
int x = 10; // x and y are two integers
int y = 35;
x ^= y ^= x ^= y; // "^" is xor operator
The last line is nothing but swapping the content of the two variables. If somebody hasn't seen this trick, it will be hard to understand what is going on. And imagine several hundred lines of this kind of stuff. After a few months even the programmer himself will have a hard time understanding the code.
Adopt a coding style and stick to it. This includes the format/spacing of the code, choice of variable names, remember to release memory, etc. Avoid incomprehensive variable names. Make the variable names speak for itself. The size of the source code might differ a bit, but it's already 21st century. A few kb is nothing, and it doesn't make any difference once the code compiles. But it makes your code a lot easier to read. Sticking to a coding style can also decrease your debugging time.
Use comments to document what you wrote. It might take some time to write the comments, but it will ultimately save a lot of time in code maintainance. One good strategy is, before actual coding, write down the flow of algorithm in comments, for example a list of things to do in the order of execution. Then fill the code in between comments. It's usually more efficient this way as you don't have to keep all the details of the algorithm in your memory.
Spend most of the time thinking about what to do rather than going into coding directly. Write a short summary of programming plan if needed. Most of the time, the inefficiency of coding comes from not knowing exactly what to do. It's also more error-prone if you're not completely sure what you are doing. For example, you can start by thinking about what the big parts in the algorithm are. How should one present the idea in terms of code? Then you can try to think how to break the process down to simple pieces. There are usually some parts that are used again and again, and it's good to have them as a separated function. A pretty nice way I found is to write a function for each major part of the code. Then in the main function it might look like the following. (Don't care too much about the syntax if you don't know C++, but just get a feel of how one could approach programming.)
int main() // program starts here
{
ReadData(....); // Calls a function that reads in data
Initialize(....); // Calls a function that does initialization
while(CheckIfDone(....) == false) // if not done....
DoOneIteration(....); // do one more iteration
PrintResults(....);
CleanUp(....); // clean-up the memory
return 0; // end the program
}
This way you won't get a "spaghetti" code which has everything in it in a long stream of codes. It's pretty self-explanatory too. And note the empty lines between codes of different functionality. It's an example of the coding style that makes things easier to maintain. Of course you still need to implement the functions, but it's much better to focus on one thing at a time.
Learn some basic algorithms, and familiarize yourself with some basic graph theory. And think a lot. There is a good website (http://train.usaco.org/usacogate) that helps you develop basic algorithmic knowledge. It will be some solid hands-on experience. The reality is cruel. A good algorithm can run a lot faster than mediocre algorithms. It could easily be thousands times or more. The more you know, the more efficient you can command the computers to work.
Be familiar with the tools that are available. This includes the standard libraries that comes with the compiler for example. It's not only a problem with rewriting codes that are already there, the point is that the tool you use determines how you will think about a problem.
I hope this helps, even if you don't get everything rightaway. I won't say that these are the exact guidelines, but they are certainly things for you to think about. There is some chance that you will work on a larger-scale project, and these kind of things will start to really pay off. It's good to have the habit of better-quality coding. And before you know it, you'll like programming instead of cursing all the time why your code is not working.
--FHead, 2009 Aug. 20 at Geneva, Switzerland
