I've been on a lot of projects, where people put an awful lot of time into coming up with the right coding style. Everyone of course wants to have his knack for a certain way of doing things included: "I want my opening curly brace at the end of the line." Or: "A single space between if and the following opening brace."

I've been on several projects where I've written either coding styleguides myself or had people scream at me or others for not conforming to the coding styleguide.

It all seemed like an incredible waste of time to me, because people just tend to stop caring, or find a way around your automated checks. Everyone has its own style to code, and it's healthier for a project to just accept that fact.

Because they want to focus on the task at hand instead of some guidelines that just stand in their way of building something awesome, and simply because they don't like having every aspect of their work controlled. Each developer has a different personality. That will reflect upon his code, and that's a good thing.

Instead of a document of several pages you just could've come up with four bullet points, like the Rails team has. Simple as that. No long discussions, no enforcing the rules. Let peer review do the rest. If your programmers work in pairs, you don't need a fancy coding guidelines document anyway. People will just adapt to a common coding style naturally. People will point out possible issues with code readability on the spot without the need to control and micromanage them.

The most useful coding guideline I've ever seen and used: Indent with two spaces. If you don't think so, I highly recommend this rather dogmatic Rails coding style checklist.

A confusing title, I know. But I recently upgraded a rather big project to use Rails 2.1. Everything went pretty smoothly, but one thing bugged me, since it's not really documented anywhere: What happens if you migrate from the old numbered migration scheme to the new one using UTC timestamps?

The new migration system dumps every migration ever run into a new table called schema_migration. That of course includes your old migrations, at least those that exist in db/migrate at the time you first run rake db:migrate on a Rails 2.1 project. It will silently drop the old and trusty schema_info table, and from then on you're good to go to use the new naming scheme for migrations.

So migrating a project to use the new migration scheme is as simple as running rake db:migrate once. Check that the table schema_migrations hasn't been created accidentally though. That will just fail inserting the existing migrations.

There, that was easy.

Tags: rails

There's a small pitfall when using git-svn. I just recently had the problem that someone renamed a file from lowercase to uppercase in our Subversion repository. Why should that bother me, when I'm using Git, you ask? Well, I'm using git-svn, and it didn't really like that kind of change. The default on Mac OS X file systems is that they are case-insensitive. FFFFFF.gif is the same as ffffff.gif.

Speaking of which, that was exactly the file that has been renamed. Doing a git svn rebase failed miserably with the error that ffffff.gif would be overwritten by the merge of the commit in question. Gah!

It took me a while to find a way around it. If you delete the file in question, just from the file system, not from the Git index, mind you, you can merge the branch in question, and have it restore the file as if nothing happened.

The steps are pretty simple:

$ rm file/in/question.gif
$ git merge trunk

The file should be restored in all its renamed glory. It works because all the stuff from the Subversion repository sleeps quietly in a branch called trunk, together with all the metadata git-svn requires.

You won't have that problem when using plain Git, though to rename the file you have to use git mv -f, but git-svn apparently can't handle that situation.

Tags: git