I wanted in this article to cover 10 of the things I've learned over the years being a professional programmer that really helped me improve the quality of my code and my overall productivity.
1. Never ever duplicate code
Avoid duplicating code at all costs. If you have a common code segment used in a few different places, refactor it out into its own function. Code duplication causes confusion among your colleagues reading your code, it causes bugs down the line when the duplicated segment is fixed in one location and not the others and it bloats the size of your code-base and executable. With modern languages its become possible to get really good at this,
2. Notice when you start distracting yourself
When you find yourself flicking to facebook or twitter instead of working on a problem its often a sign that you need to take a short break. Go grab a coffee away from your desk and talk to your colleagues for 5 minutes or so. Even though this seems counter intuitive, you will be more productive in the long run.
3. Don't rush the solution out the door
When under pressure to produce a solution to a problem, or to fix a bug, its very easy to get carried away and find yourself rushing, or even missing out your usual crucial testing cycle completely. This can often result in more problems and will make you look less professional in the eyes of your boss and colleagues.
4. Test your finished code
You know what your code is supposed to do, and you've likely tested that it works, but you really need to prove it. Analyse all the potential edge cases and make a test which confirms that your code performs as expected under all possible conditions. If there are parameters, send values outside of the expected range. Send null values. If you can, show your code to a colleague and ask them to break it. Unit testing is a formalised approach to this.
5. Code review
Before you promote your code into source control, sit down with a colleague and explain exactly what your change does. Often just by doing this you'll recognise mistakes in your own code without your colleague saying a word. It's much, much more effective than just reviewing your own work.
6. Write less code
If you find yourself writing a lot of code to do something simple, you're probably doing it wrong.
The less code you write the better. Less to debug, less to refactor, less to go wrong. Use with moderation; readability is just as important, you don't want to make your code less readable by doing this.
7. Strive for elegant code
Elegant code is highly readable and solves the problem at hand with the smallest amount of code and machine action possible. Its quite difficult to achieve elegant code in all circumstances but after programming for a while you start to get a feel for what it looks like. Elegant code cannot be improved by refactoring anything. It makes you happy to look at it. You are proud of it.
8. Write self documenting code
Comments are a very important part of programming for obvious reasons, but self documenting code can be even better because it makes it possible to understand code just by reading it. Function and variable names can often be deftly chosen so that when put together with the language semantics the code becomes readable even to non programmers
9. Don't use magic numbers
Numbers just inserted into the code are bad practice because there is nothing to describe what they represent. This is compounded by duplication; where the same number is used in multiple different places in the code. One will get changed and the others missed leading to bugs. Always use a named constant to describe the value you want to represent, even if it is only used in one place.
10. Don't do manual labour
Humans are very good at making mistakes when doing a series of actions. If you have a build deployment process which is more than one step long, you're doing it wrong. Automate as much as possible, reduce the chance of human error. This is especially important with tasks which you perform a lot.