EDIT: Well. Apparently it did show up, but with a longer delay than usual.
Computers, technology, games. And other ramblings. And sometimes in Swedish.
Friday, May 22, 2009
More blogger.com weirdness
I just published a blog entry I wrote a couple of weeks ago, but never really finished. I thought the post would be dated when I pressed "Publish Post", but instead it is dated the time the draft was created. Which means that it doesn't show up in the RSS feed. Urg.
Auto-formatting source code
Code formatting is a sensitive subject. There are countless articles, blog posts, and other texts available on the subject. Everyone who's worked with other programmers knows that most programmers have a pretty good idea on how they want their code. Tabs vs spaces, 2/4/8 steps indenting, where to put the braces, etc.
There are several studies (see Death to the Space Infidels! for example) indicating that consistent code formatting improves team productivity. The hypothesis is that it is easier to read and understand code which follow certain rules. Atwood quotes a study on chess-players which compared the ability of remembering the layout of a chess-game. When the pieces were laid out as they might be in a game, the expert's memories were far superior than the novices, but when arranged randomly, there was little difference. The same type of idea seems to hold true for programmers as well.
I've written quite a lot of Java in Eclipse lately, and have become very fond if the "auto-format on save" feature introduced in Eclipse 3.4 (I think). The idea is that given a fairly detailed set of formatting rules, your editor (Eclipse in this case) formats your code automatically before saving. When I first tried it, I thought that it would be annoying and intrusive, but the feature turned out to be very nice. So nice that now I get annoyed when stuck in an editor which doesn't do this for me.
I started thinking about it, and realized that code formatting in this respect is a lot like code generation. Source code is just another representation of your program. It is different from the compiled code (or any other representation) because it is intended for human consumption and processing while the compiled code is designed to be executed in hardware. Compiler writers spend lots and lots of time making the compiler generate good code (which usually means "fast", but could also mean "small", or a combination of the two). In the same way, source code needs to be properly formatted for it to be efficient, i.e. easy to read and edit by programmers. This is a task which in very many cases can be automatically handled by the editor (or an add-on program).
The Java editor in Eclipse does this very well. Compilation and source code formatting is performed incrementally so there is no noticable delay while typing. However, there are a few drawbacks. One problem is with code which is commented out using block comments. Since the editor doesn't recognize it as code, it is formatted as ordinary text, making it unreadable. I usually work around this using "if (false) { … }". The other problem is that the formatter has a few blind spots. Complex boolean expressions are not indented in any structured way, and certain patterns of chained method calls are indented at the line width, instead of aligning. If you use the Builder design pattern, you'll know what I mean.
There are several studies (see Death to the Space Infidels! for example) indicating that consistent code formatting improves team productivity. The hypothesis is that it is easier to read and understand code which follow certain rules. Atwood quotes a study on chess-players which compared the ability of remembering the layout of a chess-game. When the pieces were laid out as they might be in a game, the expert's memories were far superior than the novices, but when arranged randomly, there was little difference. The same type of idea seems to hold true for programmers as well.
I've written quite a lot of Java in Eclipse lately, and have become very fond if the "auto-format on save" feature introduced in Eclipse 3.4 (I think). The idea is that given a fairly detailed set of formatting rules, your editor (Eclipse in this case) formats your code automatically before saving. When I first tried it, I thought that it would be annoying and intrusive, but the feature turned out to be very nice. So nice that now I get annoyed when stuck in an editor which doesn't do this for me.
I started thinking about it, and realized that code formatting in this respect is a lot like code generation. Source code is just another representation of your program. It is different from the compiled code (or any other representation) because it is intended for human consumption and processing while the compiled code is designed to be executed in hardware. Compiler writers spend lots and lots of time making the compiler generate good code (which usually means "fast", but could also mean "small", or a combination of the two). In the same way, source code needs to be properly formatted for it to be efficient, i.e. easy to read and edit by programmers. This is a task which in very many cases can be automatically handled by the editor (or an add-on program).
The Java editor in Eclipse does this very well. Compilation and source code formatting is performed incrementally so there is no noticable delay while typing. However, there are a few drawbacks. One problem is with code which is commented out using block comments. Since the editor doesn't recognize it as code, it is formatted as ordinary text, making it unreadable. I usually work around this using "if (false) { … }". The other problem is that the formatter has a few blind spots. Complex boolean expressions are not indented in any structured way, and certain patterns of chained method calls are indented at the line width, instead of aligning. If you use the Builder design pattern, you'll know what I mean.
Monday, May 18, 2009
Friday, May 15, 2009
Eclipse, Subclipse, and Jaunty Jackalope
Getting Subclipse 1.6.x to work with Eclipse 3.4.x and Jaunty Jackalope was a little tricky. It turns out that Subclipse 1.6.x is too new for Jaunty, so you need to roll your own Subversion/Java bindings. (Fortunately I already had a colleague at work do that for me).
The crucial step which is not done automatically is to add the path to the libsvn-javahl-1.so library to the JNI load path. This is done my adding the following line to eclipse.ini, after the "-vmargs" parameter:
The crucial step which is not done automatically is to add the path to the libsvn-javahl-1.so library to the JNI load path. This is done my adding the following line to eclipse.ini, after the "-vmargs" parameter:
-vmargs
...
-Djava.library.path=/usr/lib/jni
Wednesday, May 13, 2009
Broken camera
The other day I was planning to bring my (and my wife's) Nikon D40 along to take some pictures when I realized that the memory card reader did not lock the SD card properly. Pressing the card in usually locks the card in place, but now it just pops out again. Depressingly enough, the local camera store I went to here in Uppsala wanted 500SEK (~$60) just to send it to the repair shop, and estimated that fixing it would cost at least 1500SEK (~$190).
Maybe this is a sign from above that I should upgrade to a D60.
Maybe this is a sign from above that I should upgrade to a D60.
Tuesday, May 12, 2009
Blog weirdness
I had a blogpost "Christmas" which seemed to have disappeared. It did not show up in my blog archive list, but searching for "Christmas" turned up the post, so where did it go. I changed the blog archive box to use a flat layout, which looked like this:
In the blog archive list there are now 2 (!) entries for March:
http://thisisnotaprogrammersblog.blogspot.com/2009_03_01_archive.html, and http://thisisnotaprogrammersblog.blogspot.com/2009_03_31_archive.html.
Can anyone enlighten me about what's going on?
In the blog archive list there are now 2 (!) entries for March:
http://thisisnotaprogrammersblog.blogspot.com/2009_03_01_archive.html, and http://thisisnotaprogrammersblog.blogspot.com/2009_03_31_archive.html.
Can anyone enlighten me about what's going on?
Friday, May 8, 2009
Getting rid of the mouse
I'm making a serious attempt at learning how to use Windows without a mouse, primarily because I feel that moving my hands between the keyboard and the mouse is slow. So, here goes.
I've already discovered problems with several programs. (If I'm wrong, please tell me!)
- The very first item on the list is to install the Mouseless Browsing add-on (MLB) to Firefox. It adds little numbers to every hyperlink, allowing you to click on any link using a number instead of tabbing.
- Know the necessary windows shortcuts.
- I have a multi-monitor setup, so I want a shortcut for moving windows between monitors. Since I have an nVidia graphics card, I can use nVidia's desktop manager to add a shortcut (Alt+` in my case).
- Learning Eclipse keyboard navigation. 10 Eclipse keyboard shortcuts every programmer should know.
I've already discovered problems with several programs. (If I'm wrong, please tell me!)
- Digsby's preferences page does not have any support for keyboard navigation.
- WinAmp doesn't have any way of minimizing itself (Alt-F10 does not bring up the window's system menu)
- Blogger preview function is not keyboard accessible, and the HTML compose widget interacts badly with MLB, since the numbers inserted by MLB are kept in the HTML code for the blog post.
Subscribe to:
Posts (Atom)