I’ve not had chance to do as much more research into the various Agile flavours (next post) as I’d hoped this month. Instead, I’ve been thinking of ways to improve the quality of the code written by myself and and my team at work, whose focus for the year is on quality. To do this I’ve compiled a coding style guide which is based on the CakePHP coding standards but with some additional guidelines, and this; The Programmer’s Manifesto. So, in the absence of anything else to blog about, I thought I’d post this – it might be useful to someone else, maybe ;-)

1. Follow the guide
   Adhere to a coding style guide. By following a guide, code becomes more legible and more maintainable by more people. This includes work on existing code that may not follow your style guide. Any new, non-trivial stuff you do, should be adhering to your guide and if possible within the time constraints, any existing code should be rewritten in your style. Decide this on a value-added, case-by-case basis. Small tweaks should obviously follow the existing style. Having a style guide in place that you require contractors to adhere to will also be beneficial once they’ve completed the project and its down to you to maintain it!
2. Test everything
   Whether it be implementing a new feature, changing existing functionality or fixing a bug, test it, test all scenarios, test everything a dumb user might do, even if it takes ages and is a real pain, and test it locally, then on staging then on live. Don’t rely on other people to test it. Never assume any code you “tweak” will work, always test it, even if its only a small change. If testing means filling out long forms, do it, or sending emails, add your address to the list.
3. Describe your code
   Add phpdoc style comments to all methods. Add inline comments for any code that requires it. Such as anything that someone else might not understand, or you might not when you come back to it 6 months later. The more understandable your code is by more people, the less likely you will be pigeon-holed on that project in the future, being the only one who can work on it. Its no fun working on the same project all the time, allowing others to easily work on your code, frees up your time to work on more interesting and exciting things.
4. Describe your commits
   Add commit messages to every commit. This helps anyone merging branches to understand which revisions to merge. It also helps you figure out what you did when, which is especially useful if you have to fill in time sheets or your boss asks what you did last week when he was away. Figure out how to configure your subversion server to require commit messages (google it).
5. Stay DRY
   Don’t Repeat Yourself. There is never any excuse for copying and pasting code into another place. Even if its a new feature that’s similar to an existing one, always refactor the existing one and make both things use the same logic. Make use of components, helpers, behaviours, elements – especially elements, never repeat blocks of markup if you can help it.
6. Make your code perform
   Minimise hits on the db – only retrieve data from the required tables, unbind models that you don’t need data from. If many pages on the site all have the same data on, e.g. a form with a drop down populated from the database, cache the data, don’t fetch it from the db every time.
7. Make your code secure
   Remember: Filter input, escape output. Build CakePHP find conditions using arrays not strings, strings don’t get parsed for SQL injection properly.
8. Be MVC strict
   Put all code that does anything with data into your models, then call model methods from your controller. Keep controllers short and sweet. Only do presentational logic in your views. Write model methods that do one thing that you could easily write a unit test for.
9. Keep track of time
   Record the time you spend on a project and break it down by each of planning, coding (further breakdowns for tasks), bug-fixing/amends. When a project is finished, compare timings with your estimates, evaluate whether you need to allow more or less time for future project estimates or whether there are areas that could be improved.
10. Make progress
    Never waste downtime. If you’ve ever got nothing to do, for more than half an hour, always make progress with either personal technical development or working on features in your current project to make them more flexible and re-usable in future projects.

Some of the guys at work mocked some of my typos when I got it printed on fibre board with a funky, matrix-style background and stuck it on the wall, but they couldn’t help but agree with the principles and buy into it. Its kind of all the things you know you should be doing, but having them written down on paper makes them more important some how, and means you and your team are more likely to follow them.

Anything else you can think of? Please leave a comment below.