Most of these habits are not so bad (at least that's what I tell myself) that they are going to bring down a whole project, but a good coding practice reaps benefits; saving time, testing, number of bugs in your finalised code and even the sanity of your work mates. Good quality coding can become second nature with practice.
Coding styleI have to admit, I have the worlds worst hand writing. Beautiful hand writing is developed over years of practice. Your coding style is built up simarly over time, if you don't take time to indent your code, comment, consolidate and refactor as you go it will stay that way. By the time you reach the end of your page and look back at what you've typed you can't be bothered to go back and fix things up. It's like writing a paper and going back and dotting the 'i's once it's finished.
Get in to the habit of correctly styling your code and just like your hand writing your speed will increase over time to the point where you can write presentable, intelligable, clean written code.
Those of us with good coding styles also find it easier to switch styles on request. So if you move to another company or get a new client who requires a certain coding style you can easily adapt your current coding style.
And if your company doesn't have it's own coding style (and you really want to make friends), try and encourage everyone to develop a company standard coding style that raises the bar for everyone.
Not enough testingOh no! Oh FUUUUUUUUU! Not god damn testing. If you're the kind of person who gets violently ill when asked to test your own code then you may be pleasantly surprised to know that the more you test and the earlier you test the less number of times you are going to have to revisit the same piece of code. There's only one thing worse than testing and that's having someone else tell you your code is buggy, so make sure you take the time to test your code.
The best way to do this is to get some idea of how it's going to be used and once it's built go ahead and use it. Everyone writes buggy code, we write code fast because we can, but you can't code perfect. Apps and sites are built using building blocks, but you need to test each page and the site as a whole. Test after each section and test once you've put all the pieces together. You are more likely to find bugs testing like a user rather than testing like a developer so go ahead and click everything, try and break it and then plug those holes. People accept the fact you are going to write buggy code, but they will be surprised if you hand over a well tested piece of work. Remember these guys know how to break it better than we do, that's their job.
Read moreOne of the questions we asked in a recent round of interviews was 'what sites do you like to visit online and how do you keep your skills up to date?'. We were surprised at the number of people who didn't have an answer for this. Members of our team are crazy about the web and the latest news. Reading tech books, blogs and news articles is part of our passion for IT. It's not something we do to keep up to date, it's something we do because we love it.
Even if you're just checking out Digg or looking at a few bugs on Stack Overflow, the more you read the better your skills become. We work in an industry that is always changing and developers are being required more and more to provide clever solutions for a multitude of problems. One of the early pieces of software I worked on was a small java app for a biometric finger scanner and I was hired as a php developer. Broaden your skillset and increase your value, the net is full of clever solutions.
Cut and past codeWho doesn't cut and paste code; we do it from the one page we are working on to another, from the net or even from old apps into new apps. I do it, we all do it. The problem with cut and past code is context and understanding. You cut and paste code from one area and stick it into another you want to be sure that it's doing exactly what it should be doing.
Good suggestions are ensuring that you relook at the way the code is commented; has the context changed? update the comments. Will you understand why it has been stuck there if you were to look at the same section of code in 3 months time? Try integrating the code by rewriting it, that is, only keep the good bits. If it looks out of place now, imagine what it will look like to someone else who looks at your code.
If you need to search the net for an easy solution to a particular problem, chances are you don't understand the problem yourself enough to write it from scratch. Try and understand code and if you have time and it's a clever solution, try and learn how to write it yourself from scratch.
Programming in one environment delivering in anotherThis is one of my current bad habits. Our company standard web browser is IE6, so everything must be delivered and working on IE6. God help me if I had to debug and use web tools on IE6; I can't live without Firebug. But the big issue here is that once it's working in FF it has to be tweaked in IE6, which occassionally doesn't happen (guilty look).
This really goes back to a good personal testing regime, but if you are developing for a particular environment your works not over until you have used and reviewed in that environment. And more than likely you will find more bugs if you use that environment more often. If you have a client who wants you to build for a particular environment or setup, try your hardest to work in that environment or at least do all of your quick and full reviews in that environment. If you code in FF and need to have it working in IE, have IE on the screen next to you, only use FF to fix bugs. Finding bugs saves you time rewriting the same code again.
Usually sites like these suffer from speed, usability or functionality just doesn't work quite right. Try and get an understanding of how a good working application is put together and find a good balance between front and back. And as always, the number one rule of usability, don't put useless shit into your site.
Comment, Comment and More CommentsHow many times have I looked at code I wrote 4 weeks ago and have no idea why the hell I wrote what's in front of me. It's painful. Commenting is not only useful for yourself, but you should consider it a courtesy. You can also usually tell how good a coder someone is by how good there commenting is. Why? Because commenting is human readable, you can read it a lot faster than code, you can immediately see if someone understands what their code is doing.
Commenting is a quality not a quantity thing, but more often than not it's lacking, so I suggest to aim for slightly over commented rather than commenting where and when you think necessary.
Also as suggested elsewhere, if you touch a piece of code that is already commented, read the code and update the comments. Out of date commenting is just as dangerous as incorrect code.
If you have any suggestions (or confessions) of coding habits that should be changed in this new year (and decade) let us know in the comments below.
Have a great new year and happy coding!