1. Duplicate code throughout the program

If you write code which is duplicated in the program it can be hard to maintain and can introduce bugs. You may think you have made the change to the code, but then find out the same method was duplicated in a different file and wasn't updated when you made the change. Causing different results, essentially a bug. This is why you should avoid duplication as much as you can. You should put this method in a location which can be called by different sections of the program. When you need to change the method later on, you only need to change it in one place, rather than search for or miss the duplicates.

2. Introducing new bugs after making a change

When you make a change to a program, or you add a new feature, you run the risk of introducing new bugs into the program. You can help to prevent this by writing unit tests. You write unit tests in a separate project to test the methods and functions in your program are working correctly. A test is written to make sure that a method does what it is expected to do, or that a method is called when it is supposed to be. The more tests your write for your program, the higher percentage of code coverage you will have. You would aim for 100%, but not many large programs get to 100% code coverage.

3. No version control

You may have added new features or changed a part of the code and put that code live. Then when the site is live, a bug may be discovered or you may be asked to remove the feature and go back to the previous version. This can be a problem if you don't use version control.

What is version control?

Version control is the process of recording changes in a program so you can go back to specific versions later on. When you work for a company, you will most likely already be using version control, probably SVN or GIT. When you are working on personal projects, you may not be using version control, so you will suffer the problems caused by this. I suggest you start using GitHub for Open-source Software projects, or install Visual SVN Server and Tortoise SVN on your machine if it is a private project.

4. Reading or writing code which is difficult to understand

When writing code, you understand it yourself, but do you know whether others will understand it too? Will you understand it yourself if you come back to it 6 months later? This is why companies have coding standards. These are a set of guidelines, rules or best practices to follow so that everyone else will be able to understand the code, no matter which developer wrote it. This covers conventions for things like naming, commenting, indenting, line length, single line or multi line methods etc.

5. Estimating how long a task will take to complete

When working as a professional developer, you will be asked how long a task will take to complete. This is needed for quoting a price, scheduling in the work and setting expectations. It can be difficult to estimate how long something will take, you need to look back at similar tasks and see how long they took. If you didn't measure how long they took, you will need to break it down into smaller tasks and make an educated guess for each item. This is why it is good to measure how long tasks take to complete. You can use this to create more accurate estimates for future tasks.

Paul Seal

A .NET Web Developer from Derby (UK) who specialises in building Content Management System (CMS) websites using MVC with Umbraco as a framework. Paul is passionate about web development and programming as a whole. Apart from when he's with his wife and son, if he's not writing code, he's thinking about it or listening to a podcast about it.

Web: codeshare.co.uk

Comments