Another unsorted list of ideas this time about coding tips.
code = mass
The source code isn’t an abstract element. OK it’s not as touchable as apples or bricks but it’s somehow under physical laws too. You must write as less code as you can to meet your requirements. Big code means big mass and if you have a big mass you will need more energy to change whatever you need. I can stop a car toy with my hand but I need something more to stop a real train with the same speed. Less code means less failure points and it’s easier to manage. Some people claim proudly they have written a library with thousands of code lines. Nobody pay us for writing lines of code. They pay us for the solutions. The lines of code that we write is our problem. So be as minimalistic as you can. The problem is that writing less code is more complicated than write more. We need to think more to write less code.
DRY (Don’t repeat yourself)
Original, isn’t it?. Copy & paste is evil. Never use it in your projects. Spread the same code among different files means that you will need to remember where are those pieces of code when a bug appear (they appear, believe me). There’re a lot of techniques to avoid copy & paste source code. Use them. There isn’t any excuse to it.
Coding standards
The source code is one of your deliverables as developer. You must care about it. Adopt a coding standard. Chose one and use it. If you work with a team take this decision with your team, but don’t try to create one standard by your own. It’s a big job. If you use one of the existing coding standards (let’s say Zend Framework’s one) you will find tools to validate your code against it and the most common IDEs and text editors will be able to use it too. In other way if you create a new one you will need to develop those plug-ins and tools and even you will need to document it if you want to show it to another developer. To many work that nobody will pay for it only because you dismiss an existing one.
Revision control.
Mandatory. Even for small and personal projects. I like Mercurial. it’s easy to use and easy to install. Anyway there are others similar like git or bazzar. Or if you are old school, CVS and Subversion. When I start a project, after create an empty folder with the name of the project I always execute “hg init” to create my repository. Commit you code often. Every time you make something important commit your work. Don’t wait until your project is finished. Revision control is a great backup system too. When something wrong happens like accidentally delete of a folder or something similar you can recover it easily without any problem. Also with a simple hg push (or similar command with another software different from mercurial) you will save your project into another place. If you don’t know to use any revision control system aside time for it. Believe me. You will not need too many time to learn how to use it. At least a basic usage.
Text editor
Is your main tool as a developer. It’s like the hammer for a carpenter. You must train yourself in the use of it. A good skill in the use of a text editor or IDE will give great benefits. If you think in term of ROI, the investment you use in your IDE will return sooner or later. Some of them are not trivial. For example Eclipse needs time to learn how to configure it. You must skill yourself into the IDE if you don’t want to lose your time developing (remember time = money). I’ve seen people programming PHP with notepad. You need at least syntax highlight, syntax error detection, auto-completion, auto-completion with code introspection and debugging. Don’t waste your time.
Gonzalo Ayuso - Web Architect 
I don’t really agree with the whole “DRY” concept. Bugs DO happen, but that’s why you put those code repetitions into functions.php kind of a file of sorts, or even better, TAG the code with an easily searchable comment such as this:
// TAG: codepiece12345
function hello () {
echo “Hello”;
}
and create your own library of code (I looked at that framework idea and I think everyone should have their own little library of their code) with the tags etc. When something needs to be changed, use the “Find and Replace” feature in so many project management programs (Dreamweaver has this feature and it searches ALL across your site and finds and replace that piece of code).
Next, errr. Can you explain to me this whole “revision control” thing? I’ve never used anything like that for my projects. Thanks!
Great article btw!
You are right in one aspect. DRY doesn’t mean no bugs. In fact bugs are inevitable. They’ll always exist. If you are really strict the method you comment is viable but there’s a problem. If you copy and paste a piece of code and you alter it you must change the comment with the tag (in all the copies). An error in the tag definition will be really difficult to detect. If you forget it the search tool won’t work. If you work alone it can be viable, but if you work within a team the probability of having errors is big. You must rely that every developer of your team is strict and they keep the comment with the up to date. I don’t recommend this method. But remember it’s only my humble opinion. But in my opinion is better to use (as you told before) a set of classes with our common task and include them into our project instead of clone each function among different files.
The other concept (SCM), please give it a chance. Believe me after using it you won’t live without it. Have a look to mercurial (git and Bazaar are similar projects). Really easy to use. I’ve been working for a long time without a SCM I felt comfortable. But now mercurial is essential for me. Imagine you’ve been working in a feature. Changing a few files, and finally you decide not to use it. You must remember all the changes you have done. Revert them. Probably restore a backup. Have you got a backup before every change? It’s a hard work and the probability of loose code is really high. Using a SCM such as mercurial this operation is trivial. hg st (to see files touched) hg diff (to see changes) hg revert (to restore previous code). Want a backup? push your code to another repository with a simple hg push. Let me insist. Let it a change. With a very small effort your productivity will be increased.