The next step is to generate methods. Eclipse allows us to define templates for various types of methods: getters, setters, other methods, constructors and catch blocks. For our purposes, we need to define getters, setters and methods.
This is the template for the getter:
return ${field};
and for the setter
${field} = ${param};
For methods, it's slightly different:
${method_body}
Simple and elegant. Just how it should be! So now, when we ask Eclipse to generate a getter and a setter for us, it will create the body and the declaration for us. But what about the comment?
There is separate set of templates for controlling automated comments. There is support for seven types of comments: getters, setters, constructors, types, fields, methods and overriding methods. In our example, we need to change the ones for getters, setters and types. Let's begin with types.
The comments for types are the ones that will appear when you generate a new class. So in our case, we want the comment template to look like this:
/**
* Class: ${enclosing_type}
*
* This class does something.
*
* Created by: Laurent Duperval
* On: ${date}
*/
The interesting element you see is ${enclosing_type} which is the name of the type for which the comment is being generated. In this case, it will generate ClassName for us.
Yes, I hard-coded my name. The templates are user-specific, not system-wide. Since I will always be the one to create the code, I'm hard-coding it. It is possible to have Eclipse insert your userid if you wish, however. Just use the ${author} variable.
Finally, the date is inserted. It will look like this: Mar 30, 2004. I'm not sure if you can change the layout according to your locale. That exercise is left to the reader.
For methods, the template will look like this:
//////////////////////////
// ${enclosing_method}()
//////////////////////////
/**
* Put some text here.
*
* ${tags}
*/
The ${tags} variable automatically inserts the needed Javadoc tags for us. To complete the Javadoc, we will only need to add the text.
The comments for the getters and the setters are more problematic. Unfortunately, Eclipse doesn't (yet?) allow us to insert the name of the getter directly in a comment. So using ${enclosing_method} is not an option. What to do? We have a couple of options: we can either convince our client to change the coding standars, or use editor templates instead of code templates.
The principles of editor templates are very similar to that of code templates, except that there is more interaction with the user. With an editor template, variables are filled in as you type instead of being automatically generated. In our case, it's not ideal but it's better than nothing.
Our editor templates are defined in the Editor instead of the code generator. As you can see in the screenshot, there are a number of pre-existing code templates distributed with Eclipse.
The code for our getter template will look like this:
//////////////////////////
// ${name}()
/////////////////////////
/**
* Get the value of ${value}.
*
* @return the value of ${value}.
*/
public ${return_type} ${name}(${arguments}) {
return ${value};
}
Ant the one for the setter will look like this:
//////////////////////////
// ${name}()
/////////////////////////
/**
* Set the value of ${var_name}.
*
* @param ${arguments} the value to set
*/
public void ${name}(${arguments}) {
${var_name} = ${arguments};
}
In order to use these templates, we need to give each of them a name. Since I'm a graduate of the Business School of Branding and Unforgettable Marketing, I decided to call mine getter and setter. Now, to use the new templates, we type their name, followed by Ctrl-Space. Eclipse will insert the code for us and walk us through every variable defined in the template, so that we can give those variables a proper value. This screenshot shows how that looks. To change from one variable to another, we need to press the Tab key.
Admittedly, it isn't as convenient as automatic code generation, but it's better than typing everything by hand.
Now we are able to generate methods, getters and setters with the proper Javadoc. Yes, we're almost there. The only thing left to do is to take care of those pesky variable names.
Automating variables names
When Eclipse generates a method for a getter or a setter, it capitalizes the first letter of the field and prefixes get or set to the getter/setter name. But a method that looks like getC_iAnInteger is just plain awful. Luckily, Eclipse can be told how to recognize different variable names.
If you have coding conventions that require you to use specific prefixes or suffixes when creating variable names, you can give Eclipse a list of those prefixes and suffixes. Then, when you generate a getter or a setter, Eclipse will strip your prefixes and suffixes and generate nicer-looking names.
You can generate prefixes for fields, static fields, parameters and local variables.
Now when you create getters and setters, pretty much all the boring work is done for you. A field that looks like c_iAnInteger will generate a decently named getter: getAnInteger().
Another bonus is that when you create new variables and press Ctrl-Space, your dropdown list will offer to create variables for you which contain your prefixes or suffixes. However, if you have many suffixes and many prefixes, this can be a problem more than anything else.
Now get to work
We now have all the pieces we need to make sure that our generated code conforms to a given coding standard. To use them, use the Wizard to create a new Class. Give your class a name, and watch how all that beautiful code appears before your amazed eyes. Then, add a new field and ask Eclipse to generate a setter and a getter for you (or do it manually if you created an editor template). They both should be generated with the proper formatting.
Finally, to create a new method, you need to type some code in the class, select the code you typed and refactor that code into a new method (by pressing Shift-Alt-M). Eclipse will replace the code by a method call. A new method will be created for you, the code you highlighted will be the body of the method, and the comments will look like what we defined in our template.
Templates are just part of what makes Eclipse such a great tool. If you aren't satisfied with your IDE and you want something better, take Eclipse for a spin. You might just like it enough to adopt it. I know I did.
I used to be one of those l33t vi coders who sniffed at anything with buttons and menus and wizards. However, the latest generations of IDEs have made me a convert. I admit that I sometimes pull up Vim to do minor code changes to a Java class, but that reflex is fading fast.
As for IDEA, yes, I still miss it sometimes. I even find myself a bit annoyed when familiar keystrokes don't give me the expected results. But if I can forget the name of the girl who gave me my first kiss, I'm sure I can forget all about the IDE I was using last summer.
About the author
Laurent Duperval has been a developer for the past ten years. He is a budding speaker and an active member of the OpenOffice.org mailing lists. He wishes he could contribute more to the OpenOffice.org and the Mozilla projects. He's a big comics fan.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
- "Templates with Eclipse, Page 1/2"
- "Templates with Eclipse, Page 2/2"
