The pleasure of block selection whilst editing code

Sometimes you wish that writing code would be easier… or at least a bit more efficient. Today I used the block selection mode (default shortcut: Alt + Shift + A) in Eclipse once again. There was a need to insert a common piece of text into several lines. The first thing I noticed was that the lines were all aligned perfectly. This made me think that block selection mode would be the best way to save some time and avoid making mistakes.

The first thing I did was selecting the block of lines that needed editing, but keeping the selection’s width to zero because there was nothing that needed replacing. Then it was time to type in the text, putting in the same words across several lines at once! Was this efficient? Yes, it was because any mistakes made will be uniform and, while I was still in block mode, the same would go for the corrections. Then I decided to blog about it, so in the end I actually lost some time on it after all.

Git rebasing to last public commit

As part of my workflow I make lots of small commits which I push to a central vcs once I finished a feature or fixed a bug. Often I find the need to re-base some of my commits interactively in git.

One reason is that I tend to forget to add something in a commit, so a fix-up I made afterwards needs to be squashed or placed closer to another commit. Another one is that changing the order of my commits will offer a better or more rational train of thought. And yet another reason is that at times my attention is so scatter I have two or more branches for features, futures or wip/dev. All those branches are based on a local master branch, which in turn is based on the central vcs’ master.

Before I used to type/copy/bash reverse-i-search the git rebase --interactive HEAD~N command. This could of course be shortened a bit to just git rebase -i HEAD~N, but it still left me with the task of figuring out how many commits I want to revise. Just guessing usually got me either to many or too little. Then I grew into the habit of firing up gitk, which in my case is an alias for gitk --all so I can see all branches, then count by hand how much commits I needed to revise and then use that number.

Although a slight improvement over just guessing it still left an error margin of 3 commits in the worst case. Then I noticed that I usually revise up to a branching point, so using git rebase -i branch/tag-I-started-to-deviate is shorter and saves time. For this to work its of course mandatory to keep feature branches short and regularly re-base all branches, including the local master branch, against its parent.

Universe type system

It is no fun when life throws you a boring day, so what’s a programmer to do but seek new knowledge? My choice was to look at this thing called Scala and of course I browsed through the site.¬† That’s when I came across the universe type system. It’s some kind of object hierarchy system with a few simple rules. Reading the paper is easier on the dark and dull days of Autumn, since they are written by academics and therefore usually dull. I haven’t taken time to read it all, these are just my conclusions for now.

In the Universe type system everything has one owner or no owner at all. The one object with no master is, obviously, the root and a unique entity in the universe. The owner of an object is the only thing that can change it. This means that if you’re not the owner you can see the value but not change it directly. This seems to solve the problem of exposing the internals. Aside from that it provides some security¬† in making sure that objects won’t change unexpectedly.

I like the simple principle from the Universe type system, only the owner can change properties of his… well properties. It’s very pleasant to know that a certain object is the only one modifying properties of another and no other can. Too often I see source code, among which mine, that seems to violate the open-closed principle. This type system goes a bit further, but in a way you could say it’s a heavier enforcement of that principle without need for the developer to think about it. Everything that lessens the effort to keep your code from unexpected behavior makes you more efficient. Something I like to be very much.