Change of Tack

The only programming I have ever know has been programming for the web. Chiefly PHP and JavaScript (with a little RoR sprinkled in there along the way), but all loosely-typed languages where it is easy to be a bit sloppy with the code and still get away with it.

In contrast, I have just started learning a bit about iPhone app development. Primarily because I want another challenge, something a little different; and partly because I am really excited about the potential that the platform holds, and I would rather be in there making things happen then watching from the sidelines. So I have started getting stuck into a bit of Objective-C, and to be honest it is something of a shock! Coming from a PHP/JavaScript background, the language seems incredibly rigid – no more getting away with being sloppy about return value types! Actually, to start with the whole thing seemed incredibly anal, but I am slowly starting to see the advantages of doing things this way.

In fact, even though I have only just started looking at it, I am starting to understand how PHP is really a kind of facilitation layer plastered over the underlying core programming language – which makes things easier for sure, but lacks the fundamental power that scripting in C can give you. Of course PHP is really optimised for web tasks, and Objective-C in turn for mobile and desktop applications, so their intention is very different and they undoubtably each fulfill their roles very satisfactorily. But I can’t help the feeling that I have suddenly had a veil lifted from my eyes and can now see that I have been programming in Fisher-Price, child-friendly languages up until now.

I mean this as no disrespect to the people who code in PHP/JavaScript etc – I do so everyday and very much enjoy it. It’s just that within those languages you are very much shielded from a lot of the more ’serious’, lower-level programming issues (such as memory management and threading) that you have to deal with in languages such as Objective-C. This is a fact that I was aware of but never really understood until I started investigating iPhone development.

So I am realising how much I have to learn, all over again, but I am really quite excited about it all. Who knows where it will lead – 5 years ago I was doing a Master’s degree in Oceanography and would never have though I would be programming for the web in 5 years time! I certainly wouldn’t be sad if I was earning a living writing Mac/iPhone applications in a few years time. But perhaps I’m getting ahead of myself…

No Comments »

Coding for others – Part 2

In the first part of this 2-part mini-series I explained why it is important to make sure you take the time to make sure your code is easy for others to pick up and understand. But how do you best achieve this lofty aim? Below are some general principles that are straightforward to implement and will go a long way to making your code clear, legible and as easy to understand as possible.

Whitespace, whitespace, whitespace

Probably the single most important thing you can do to increase the legibility of your code is to inject a good dose of whitespace into it. Dense, cramped up code is hard to scan and hard to extract information from quickly. Correctly indenting your code, together with liberal use of spaces and new lines results in a much clearer easier to scan and understand script. If you are writing JavaScript or CSS, don’t cut back on whitespace to save you a Kb or two in filesize – instead space everything out nicely and then run it through a compressor when you are ready to go live with it all, keeping the uncompressed version for later editing. Have a peek at the CodeIgniter framework source code for a great example of well formatted code with plenty of whitespace.

Make it self-documenting

Good code doesn’t need pages of comments to tell you what it is doing. Careful choice of variable and function names can go a very long way to making your code speak for itself. Stay away from non-standard abbreviations and generic names (like ‘value’ of ’set_value’) where possible, and try to make sure all of your function names are really representative of what the function actually does, and variable names describe accurately their contents. The CodeBetter site has a good post on self documenting code = check it out for loads of good tips.

Create a set of conventions, and stick to them

Nothing is harder to get your head round than code that doesn’t follow a cohesive set of conventions. It is really, really important that you develop a set of conventions (or adopt ones from somewhere else) for all the code that you write, and then stick to them religiously. The actual conventions don’t even matter as much as the sticking to them; what you are aiming for is uniform, consistent code standards across and within projects. This goes for naming of functions, variables, file names – everything, even the amount of whitespace. Write down your conventions if you need to share it across teams – Zend’s ‘coding standard guide‘ for their Zend Framework is a great example of a comprehensive manual of coding and naming conventions. Obviously for your own personal projects it is unlikely you would take it this far; but however far you go it will make it much easier for people who have looked at one piece of your code to pick up another and immediately feel at home.

Comment enough, but not too much

Comments in code are often invaluable for providing information as to the purpose of a particular line, function or other segment of code. In an ideal world the code itself would be entirely self-documenting (see above) – however in reality this is rarely (if ever) achieved, and a few helpfully placed and concise comments can work wonders. But keep the comments short and sweet! A 30 line comment, unless absolutely necessary, will actually hinder understanding of the code, as it adds to the visual ‘noise’ in the script and most people are highly unlikely to actually read it all! Besides, if a function (or anything else) needs 30 lines of comments to explain what it does it is very likely that the real problem is in the clarity of the code itself.

Don’t get too fancy

Whilst it is tempting to condense a 10 line ‘if’ statement into one line by stringing it together into a triple-nested ternary operator expression, this does not necessarily help with the general maintainability or readability of your code! It might get you top geek marks from the most hardcore of programmers, but generally it is not bad thing to split up complex statements to make it clearer to those charged with understanding your code.

Write better code, and less of it

Okay, so maybe this isn’t so easy to implement. But the amount of code you write, together with the quality of it go a long way to making it easy to understand (or not!). Stick to the DRY (Don’t Repeat Yourself) principle, and look at every piece of code you write to see how you can improve it and cut down on the number of lines it takes achieve your aim. Shorter, more concise code that fulfills the same role will generally be easier to understand than a long, rambling, poorly written script, as long as it doesn’t break any of the principles outline above.

So these are a just few things that you can do to improve your code’s maintainability, and make it easy for others (or even yourself!) to pick up the code later on down the line and easily make sense of it. No-one is perfect, and I certainly deviate from these guidelines form time to time. But following these general principles will go a long way to making your code accessible to others.

No Comments »

Coding for others – Part 1

This is part one of a two part mini-series. The second part goes into more detail on tips for improving your code’s readability and maintainability.

The vast majority of developers will, at some point in their career, use code written by a third party. This might be code written by a co-worker, a little snippet from a repository such as Snipplr, or a comprehensive language framework such as CodeIgniter or jQuery.

Now if you have actually ever had to go beyond just using any code written by others, and instead had to delve into the guts of the code itself, you will probably have seen a mix of code quality. Poorly written code can be a nightmare to understand. Well written code, on the other hand, can make it feel like you are reading prose; you can instantly get a feel for what is happening. Typically, well established code libraries will tend to have clear, easily readable code, whereas your co-worker might be turning out code that looks like it is written in Klingon.

So what does your code look like? How easy would it be for other people to pick up your code and figure out what it is doing?

Even if you are working on your own, writing code intended just for yourself, it is important to have a strict coding standard that you work to. You never know in the future who will have to look at your code and figure it out. And even if that person in the future is you, it is amazing how quickly you forget what a particular function or class does. The extra time taken to carefully craft and comment your code so it is easy to pick up again after a break will be paid back a hundredfold when you don’t have to hunt through file after file tying to figure out what your mind was thinking when you wrote it.

If you are writing code explicitly intended for others to use, then the case for clear, expressive code is even more pressing. It is your obligation to ensure that the code is as readable and easy to understand as possible; doing so will benefit you as well as your users, helping to cut down on requests for help or clarification. Good code speaks for itself and needs little documentation.

So how do you make your code easy for others to follow? In the Part 2 of this series I will go into detail on how you can make your code expressive, easy to read and simple for another developer to pick up and understand.

No Comments »