Programming is part engineering and part communication.
Programming is engineering in the sense that the result (the program) is an artifact that works--it does something that is useful in its own right. Getting a program to work is hard, particularly when you're a beginner, and you should feel proud of yourself when you get it working. That's also why the majority of your grade on a programming assignment is based on just whether the program works at all. In my class, a working program will receive a minimum of about a 70--a passing score for a working program. The rest of the points come from the efficiency of the program, which is another aspect of the engineering task,) and its style, which is important because programming is communication.
Programming is communication because programs are not just read by the compiler, but are read by other programmers. In school, they are read by your professor or your teaching assistant, and in industry, they are read by co-workers, review committees, bosses and people who replace you when you leave. In fact, the person reading the code may well be yourself, six months later, when you have to go back and fix a bug or add a feature. All of those people need to be able to understand the program without having to ask you. In school, it may seem silly to explain to the professor what the program does, but it's no more silly than explaining the war of 1812 to your history professor. The educational goals are to improve your communication skills and to ensure that you understand the material. The task for you is to pretend that the person reading your paper or program doesn't know anything about what it's supposed to do.
There is, of course, a balance to be struck, between explaining too much and explaining too little. In your history paper on the war of 1812, you could probably omit that Britain is a small country northwest of France, and the U.S. is a large country in North America. Similarly, in explaining a program, you can assume that the reader knows the programming language. Therefore, for example, you would never do the following:
i++; // increase i by one
You should assume the reader knows enough C++ so that they know what
++ does. However, the reader may not know, depending on what
i is, why you are increasing i. Keep
purposes in mind when explaining your code.
In literature, style is what distinguishes one author from another, such as Hemmingway from Joyce. If those two authors described the same event, the two stories would be remarkably different. Maybe we would enjoy reading both, find both equally understandable and equally valuable as a contribution to literature; maybe not. In programming, thre are still stylistic differences among authors, but the differences are smaller, and the standards are more exacting, because of the engineering task (two programs to do the same thing will have to be pretty similar) and because of the overwhelming emphasis on clarity. Therefore, programming style is not an opportunity for you to be creative; indeed, many companies have a policy on proper programming style that is rigidly enforced.
Programming style is a time for you to step back from your program, take a deep breath, and try to write it and re-write it until it is as clear as possible. This document will review a number of issues and aspects of programming style and give guidelines and suggestions.