A post in English, for a change. This morning I was configuring my Eclipse workspace to work on my master thesis project and found something interesting. I was not really into working on the project, so I decided to make a small tutorial showing the "save actions" feature from Eclipse 3.3. There probably is some better tutorials out there about this.
Eclipse is a great IDE, and the more I use it, the more I believe in this. Today I came across the save actions feature, new in Eclipse 3.3. Didn't think it would be so great. For a start, you can make Eclipse format and organize your imports after every save. This alone might save the lifespan of some keys in your keyboard, if you are a freak like me that can't write more than a few lines of code without issuing the combo ctrl+shift+f and ctrl+shift+o :). The save actions can be configured in
Window -> Preferences -> Java / Editor / Save Actions.
This is the preference page:
After enabling it, you can right away tell Eclipse to format the source code and to organize imports. It'll use your project defaults in every file.
The additions actions section has lots of treasures, and I'll walk trough each one of them. When you click on "Configure" a screen will appear with some tabs, each one for each action category. The leftmost one is
Code style that goes very well with the code format options.
Most coders have they own coding style, but when working in a coding team some care must be taken so that the great number of individual coding style doesn't jeopardize productivity. Most companies define their "coding standards" that every single programmer is required to follow.
One of the things that can be enforced by a code style is the use of blocks (or curly brackets) for single-statement control statements. While some might say that not having the brackets reduce the visual complexity of the code, others might say that not having them at all is "bug door" waiting to be open. Whatever is the policy, Eclipse can help enforcing it.
On the "for" side of the things, I'm not really sure if using the enhanced for generates better code at all, but one thing I experienced. It certainly does help in code reading. You see the enhanced for structure, you know that for is iterating over an specific array, the line is shorter than the regular Iterator use. And I also know that going trhough an old Java 1.4 code and converting the fors to the enhanced version is boring. No challenge at all and you just waste some effort time. Why don't let just eclipse handle it by selecting the "Converting for loops to enhanced"? It is pretty smart, but has its limitations.
The following code will not be converted:
for (Iterator iterator = list.iterator(); iterator.hasNext(); ) {
Number number = (Number)iterator.next();
/* ... */
}
I can't see a clear reason, but my guess is that it would be just complicated to ensure in a safe way that every iterator use in a raw type list is safe to be converted (someone correct me if I am wrong, but in my tests here this was not converted).
The conversion works for arrays too:
public void method(int[] array)
{
for (int i = 0; i < 2 ="=" 2 ="=">Rename action :). One limitation it has that I can't really see why is that if had you wrote the for increment as
++i instead of
i++ the loop wouldn't be converted.
More on the code style, you can tell Eclipse to handle your parenthesis also, by reducing the number of parenthesis, letting him cleanup unnecessary ones, or by summing up a great number of them by always surrounding the expressions.
Another thing it can manage is the existance of the final modifiers. Some like to have private fields that are never modified marked as final. Others say that parameters should never be reassigned, and so on. Eclipse can add
final modifiers to private field, paramters and local variables. Just choose your preferred combination :).
A few words on member access rules. It's possible to have Eclipse to policy your use of the qualifier to non-static members. Some programmers like to have all non-static members qualified with a
this, others avoid having this at all (by naming non-static fields with a leading or trailing _, or with some prefix such a 'm', etc), and others just like to have the
this when it is necessary. If you are on the latter 2 groups, tell Eclipse to just use
this when necessary, or if you are in the first, let him ensure every access is qualified by
this. Works for methods and fields.
You can as easily let Eclipse handle your access to static members, by qualifying field or method accesses so every static access will have the class qualifier even in the declaring class. You can also let it change static access through subtypes (for instance, using a member of IResource from an IFile class), or through instances (using a member from IResource from your local variable instance). Eclipse can be programmed to show compiler warnings for those 2 items, but isn't it just better to just have him solve the problems?
During the lifecycle of a source code, many members will be introduced, some other will be removed, and some will just loose the purpouse but will be left unremoved because the programmer didn't see them. This is another situation that ever since I can remember Eclipse is good in warning us, but now he just be configured to solve the problem by himself by removing unused imports, removing unused private members or unused local variables. Just let him remove the garbage. Casts and $NON-NLS$ tags can also be automatically cleaned up.
But wait! Eclipse is not just powerful to remove code, he can also insert some stuff. But, it's easier to destroy than to construct, so the options to insert code are just a few, yet they are useful. You can let Eclipse ensure that every overriding method has its @Override annotation, so if for some reason the original method is removed it is just easier to figure out that the code won't work (it'll not even compile, to be honest).
Eclipse can insert the new @Deprecated annotation to members or classes that carry the old @deprecated javadoc tag.
And in the very end, you can have Eclipse doing some code organization for you. If you have strict policies over trailing whitespaces (you know, that extra whitespace that the IDE inserted when you decided to add that extra blank line before the method by placing the cursor just before the declaration and not on the first column), you can let Eclipse wipe them, or wipe them only if the line is empty, or leaving them alone. The choice is all yours.
And another little help Eclipse can do is if you have policy for member ordering, such as "place all your constructors togheter, after the fields" and so on. You can have Eclipse applying the "Sort members" action in every save, so you can guarantee the members are ordered.
You could've figured out just about everything I wrote here, but hey, I had a sunday to waste ;).
