I always try my best to write extremely neat code; even if I fail. I’m a complete stickler for it. I think it’s because as a programmer one of things that frustrates me most is looking at messy code. Before I can even begin to start solving or understanding the logic involved I often spend time sorting out the indention. Whilst doing that I’m usually thinking “this should already be done, not many clients are particularly willing to pay for time spent on this”. The idea of re-factoring bad code is a difficult sell; we’ve found explaining the long time benefits and future time saving can help.

I think my C programming tutor back at uni grilled it into me, that the code just has to be neat and well organised, even if it doesn’t work initially. Thinking back it was probably just to make her life easier, seeing as she had to review it all. But hey the result it’s had on me is hopefully a good thing, helpful to me and others who look at my code.

Building Rails applications daily does tend to help with many conventions; most of the code I pick up has that going for it, although staying DRY, useful comments, good documentation, sensible variable names and consistent indentation especially are often slightly lacking.

Everybody is probably guilty of thinking I’ll just get this working first, then I’ll organise it afterwards. The problem I’ve found with that approach is it very rarely gets sorted, leaving your perfect solution looking a little wilted, confusing and quite simply messy. If like me you feel you could improve and would like to perfect the readability of your own code, I suggest you checkout the Top 15+ Best Practices for Writing Super Readable Code article posted this morning. It’s a great tutorial; just imagine the hours we could save ourselves in the long run…