By definition, dynamic languages have no concept of variable types. This means there is no need for a type declaration… so for example, in Python or Ruby you can just write:

randomNumber=4

Some statically typed languages also allow the type declaration of variables to be omitted. But since the language is statically typed, where the does the variable type come from? A reasonably smart compiler can infer the type of a variable by looking at how the variable is used. Haskell and Scala are two examples of such languages that allow implicit typing and then determine the types through compile time type inference. This allows you to write the following scala code:

var randomNumber=new BigDecimal(4)

The type of randomNumber is java.math.BigDecimal. This avoids having to type BigDecimal twice… once for the variable type declaration and once for the constructor. Since Eclipse has a full blown Java compiler under the hood (a fairly smart one), it allows you to do almost the same. You can basically omit the type declaration altogether, and when Eclipse complains just, hit Ctrl+1 and select the appropriate option. The official name for that shortcut is Quickfix, but I like to think of as: “Dear Eclipse, I’m just too lazy, why don’t you fix it for me?”

I don’t know whether this quickfix was created with this usage pattern in mind, but I find myself using this quite often. A close relative is the Extract variable refactoring which also does design time type inference. Another refactoring where type inference comes into play is Generalize declared type, which lets you reduce the specificness of a variable type to its lowest common denominator.

I am sure there are a number of similar refactorings and quick fixes. These powerful features demonstrate how a smart IDE can make working with a statically typed language much easier, while still reaping the benefits of static type checks.

What are your favorite type inference shortcuts?

Java Settings

I recall being at a client site doing some code review… when people all the sudden started bickering about if ‘if’ statements should always be closed or not and where the ‘{‘ should go. It happened that each team member had their styles that were different from what the team lead wanted. A part of me wanted to see how long the argument would go on for… but I decided instead to show them the excellent formatter options provided by JDT:

I could see the team lead’s eyes light up when he could configure these settings on a project level basis. The ability to enforce a style he wanted his team to share can save a lot of stress. Next, I told him I even had something better up my sleeves… save actions. Why have to manually format your source when you can do it when the file is ACTUALLY SAVED? I pointed him to the ‘Save Actions’ preference page:

In there, he was excited to find that you can format code on save along with organizing imports (amongst other things). However, this is only part of the story. There are a lot of other project level settings that are useful like compiler compliance settings. You can setup different projects to comply with different versions of Java depending on your needs. The point here was that you can setup a consistent level of settings to be shared by your team so when they check out the project they need to work on… they have all the settings to not conflict with the rest of their team.

Plug-in Settings

If you’re developing plug-ins, PDE provides some project level settings also. You can setup settings to flag errors if you’re missing NLS’d strings or using things like deprecated extension elements. In 3.5, you will be able to enforce versions on things like imported packages, exported packages and required bundles. Feel free to explore what you can do!

Sharing Settings

So now you’re thinking… how do I share these settings once I create them for one project? Do I have to manually craft settings via the preference pages for each project? The answer is no, however, the solution to share settings amongst projects isn’t very pretty. The easiest way to do this is to simply copy the ‘.settings’ folder over from a project that was previously setup to the new project:

This is the approach that is commonly used in some Eclipse.org projects. For example, in Equinox, the settings are available in a webpage for consumption. Be warned that you should only copy the preference files you need, you may be bringing some preferences you don’t want, so just becareful.

It’s my hope that in Eclipse 3.5, we can address some of the usability issues in sharing preferences across projects. If this issue is important to you, feel free to file a bug.

Conclusion

So what did we learn? Hopefully, that project level settings rock and there’s no excuse to not use them. There may be some usability quirks in sharing the settings with new projects, but that shouldn’t stop anyone in using something that can save you a ton of time.