We all know what we should be doing when writing code. Each methodology you choose to use has it’s own best practices, whether it’s working from full specifications, writing unit tests first, programming in pairs, yadda, yadda. But, as developers, we’re only human, and we’re lazy. We have tools to make things easy for us. Here are a few tips that you can use to help when you’re not as rigorous in your coding as you should be.

Use the static analyser.

You can use the Clang Static Analyser in Xcode by setting a build option. This will find a whole host of errors in your code, even down to unconventionally named functions.

Now you can just code away and have the compiler pick up your mistakes when you run ‘Build and Analyze’ (⌘+Shift+A).

Find your mistakes quickly.

Any real application you develop will have a large number of resources that need to be copied to your application bundle. The default projects that Xcode create for you will copy these files first before compiling.

But, the lazy Xcoder knows that there are probably errors in the code that need to get flagged by the compiler, so this copying is a waste of time. Reorder the build steps by dragging so that the compilation is done first.

Your builds will now break early (and often!).

Don’t fear the version controller.

I’m going to stick my neck out and say that if you’re not using version control you’re an idiot. The lazy Xcoder uses a powerful system that lets him or her branch easily, make lots of little changes, and lots of mistakes (that can be backed out). These changes can then be bundled into larger commits to be merged into the main branch so that your co-workers don’t see what an idiot you’ve been.

One such version control system is git. The lazy Xcoder writes a bit of code, checks it in out of habit and then compiles. The compiler picks up the mistakes, and he or she fixes them. Rather than make a new commit, and retype the commit message, just call:

1

git commit --amend -a -C HEAD

This will bring up the previous commit message in the editor, which you can amend if you wish. This new commit will replace the previous one. The -a option means you don’t even need to do a git add and the -C HEAD option means it will use the commit message from the last commit.

Of course, if you’re a rockstar programmer, you don’t make mistakes at this level. But I’m not, and I prefer to work with human nature rather than against it.

A while ago, I read a nice write up about using mercurial with SubEthaEdit and Changes. Here’s how to do the same thing with git instead of mercurial, separated into two parts in case you just want to apply one set of changes.

Changes Support

Step One: Make sure chdiff is installed.

Open Changes.app and from the Changes menu select “Install terminal utility”. This will install the chdiff utility which is used by the script.

Step Two: Create a shell script to send diffs to Changes

Create a shell script with the following contents.

1
2

#!/bin/sh
[ $# -eq 7 ] && /usr/bin/env chdiff "$2" "$5"

Where you save this and what you call it is up to you. Mine is called ‘.gitchanges’, saved it at the root of my home directory. Make sure the script is executable.

Step Three: Edit the .gitconfig file to use this script to handle diffs.

Open your ~/.gitconfig file. This should already exist, at the very least it will contain you name and email. under the section called [diff] add the location and name of the file. You may have to edit this to make sure it points to the name and location you chose in Step Two. (Make sure to use the correct path in your setup)

1
2

[diff]
external = <path to file>/.gitchanges

SubEthaEdit Support

Step One: Download and install the mode file for SubEthaEdit

I wrote a SubEthaEdit mode for this which you can download from the github project page. Please feel free to fork it and send me patches.

Step Two: Edit the .gitconfig file to use SebEthaEdit as an external editor.

Open your ~/.gitconfig file. This time, under the [core] section, add the following line:

1
2

[core]
editor = /usr/bin/see -w -r -o new-window -j 'git editor' -m gitCommit -g 1:0

All those flags may seem daunting, but they are quite self-explanatory: the -w flag makes the Terminal wait for a response from SubEthaEdit. -r brings Terminal to the front after you’re done editing. -o new-window opens a new window for editing. I prefer this to having a new tab appear in whatever window I was working on. -j 'git editor’ this sets the text that appears in the title bar, which you can change as you wish. -m gitCommit is what sets the mode to be used for editing. and -g 1:0 puts the caret at the beginning of the file.

Now, when git asks you to write a commit message, or pick commits when running git rebase -i a SubEthaEdit window will open as the commit message editor. Make whatever changes you need then save the file (⌘-S) and then close the window (⌘-W) for these changes to take effect.

The first London NSCoder Night was a success!

Eleven people turned up, travelling from as far as Brighton and Reading to join in the fun. There was a mix of indies, learners, small Mac shops and students.

We started off upstairs at the Bunch of Grapes and then moved to the outside area for more room. The tables outside are at a comfortable height for standing around so people were able to move around to different groups. There was a food, drink and talk and the laptops came out a few times as well.

We decided that this is going to be a regular event, held at the same place on the third Tuesday of the month. Next time I’ll book a table upstairs so we can sit down more comfortably. You don’t need to tell me you’re coming, but I’d appreciate an idea of how many people are going to make it so I can reserve approximately the right number of seats.

Thanks everyone for coming out. It was a great night and I hope you all went home with as much enthusiasm for coding as I did.

So, until the next time; follow @NSCoderNightLon on Twitter and subscribe to the iCal calender to stay up to date.

It’s surprising that there isn’t an NSCoder Night chapter in London. There is a monthly CocoaHeads meeting in Swindon, and the UK Mac Dev meeting once a month in Central London, but I think that there is a gap for an evening of coding in a social setting.

So, in the spirit of “If you build it, they will come” I’m going to try and get this started. So, this Tuesday, September 22, from about 7, let’s get together at the Bunch of Grapes pub just behind London Bridge Station map. Bring a laptop (charged) and you can either sit and code or just chat with anyone else. You can work on what you want. You don’t have to show anyone what you’re working on; but feel free to ask and answer questions.

But, this is still just an experiment. Don’t know whether it will be a weekly or a monthly event. I’m not even sure about the location. I was there last week and the WiFi was a little flaky. There was a party upstairs so it was busy, but there was a high turnover (as you would expect for a pub near a train station). I still managed to get a table. But, unless we try and get together, we won’t be able to answer these questions.

So, Come along tomorrow night. Follow @NSCoderNightLon on Twitter and subscribe to the iCal calender for future meetings.

See you there.