The process of moving from beginner to expert programmer can be challenging. In the beginning, you must learn not only the rules of the language, but also how to use a compiler and understand the error messages. Moreover, you are trying to solve increasingly difficult programming problems while following what might seem like arbitrary rules for writing good code. Most novice programmers are focused on solving a given problem, as opposed to making the code look nice. To many, it seems worthless to spend time making the code look clean, because it will almost certainly be deleted after writing it. Even more experienced programmers may ignore code style in the rush to complete an assignment or finish a project.

This is bad for a few reasons. First, well-written code is easier to read and understand. It almost certainly has fewer errors, and is more efficient than code that is carelessly mixed together and never polished. Just as we discussed in earlier chapters, the time you spend upfront making sure the code is bug free, is time you won't need to use debugging it later. The time you spend making sure the code is readable and easy to maintain is time you won't need to spend later making changes or deciphering old code.

Second, good programming style is a matter of habit. Taking time to read and debug your code is slow at first. However, the more you improve your code, the easier and quicker it becomes. Eventually, you will develop habits and writing quality code will happen naturally. Without this habit, it can be easy to push style aside and worry about it later. However, the code that is being written is almost always sloppy, and it can be hard to find the time later to go back and improve it, since there is always another deadline approaching. With good habits, you will be able to write clean, readable code in even the most time-constrained situations, such as an interview or a fast-approaching deadline.

Finally, at some point in the future you will almost certainly be working with other programmers. This could be a small team of two or three, or perhaps in a company with dozens of programmers all over the world. Even if you understand what your code is doing, it is not guaranteed that your teammates will. Writing code that is hard to understand will lead to people using your code incorrectly. Instead, strive to make your code easy to use and hard to break. Take pride in how much other people love to use your code, your teammates and boss will thank you. You will appreciate it if your teammates do the same thing. At some point, you will be required to maintain other programmers code after they have left the job. You will find it much easier to do if they wrote high quality code, so write code that will be easy to work with after you have left.

Over the next few pages, we will cover some very basic but extremely important code quality tips. As we said, these come from years of reading programming, as well as teaching. Use these techniques for every single line of code that you write. Think about these techniques for every piece of code that you read. Doing so will help you form great habits.