I read a lovely article over at Coding Horror about a week back, and I’ve been thinking about how we programmers deal with code. To start with, I think there are mainly two types of programmers today. 1) Programmers who don’t care about the looks of their code, and just care about getting the product out the door, and 2) Programmers who follow all the rules they’ve read in books and on programming sites/blogs, i.e. documenting, indenting and beautifying their code.⌘
But what Jeff Atwood says pretty much sums it all up:⌘
I have a friend who works for an extremely popular open source database company, and he says their code is some of the absolute worst he’s ever seen. This particular friend of mine is no stranger to bad code– he’s been in a position to see some horrifically bad codebases. Adoption of this open source database isn’t slowing in the least because their codebase happens to be poorly written and difficult to troubleshoot and maintain. _Users couldn’t care less whether the underlying code is pretty_. All they care about is whether or not it works. And it must work – otherwise, why would all these people all over the world be running their businesses on it?
Till now, I’ve only worked on one group project. I’ve always coded for personal projects, and have written my code in a way which works for me. It’s only recently that I’ve started paying attention to what my code ‘should’ look like, so that it is easy to port and debug.⌘
This has involved adoption of ScriptDoc, which I think is an interesting concept. Documentation is a very important part of your coding, since it saves you tons of trouble if your have ‘lots’ of code. Standardizing it will result in all programmers getting ‘tuned’ to analyzing documentation in a certain way. Also, to make the entire coding process fun, I’ve switched full-time to TextMate. Let’s just put it this way: everything you’ve heard about it, and some of the things you’ve not heard, are all correct. Auto-completion, macros, in-built syntax recommendation, and custom bundles makes it just the perfect companion for any coder looking to focus on the coding, rather than the code itself (the layout and formatting, atleast).⌘
A few steps
Spending a hint of time after your coding quota for the day is over to just skim what you’ve just written to add comments here and there, remove unnecessary line-breaks, and add necessary line-breaks is a good habit. Brackets you can do without (or ones you need), indentations and things like that should also be taken care of. This hardly takes more than 15 minutes (I do it, I know), and the end product is code that is pleasing to the eye. When you sit down to it the next day, you will not feel like giving up the moment you start, because your code looks inviting.⌘
I’ve always felt that the more tempting you make something to the eyes, the more easily your mind accepts it. Why should your code be any different?⌘