Method names in Java can be named _ and why static import is a good thing

You’re kidding right? You think a method name of _ is a good thing? Then hiding it with a static import is a good thing?

It’s not april fools day. Where’s the “I’m Kidding” at the end of the entry?

Three cheers. If it makes the code in question clearer, I agree. And Ctrl Click in the IDE will give all the details someone else might need when looking at the code.

Yes, this is no joke. I’m a great admirer of readable code. Which usually includes understandable and descriptive method names (the Messages code is not that bad).

After i18ning a big project most of the code was littered with i18n constructs. This reduced readibilty of the original business code (i18n understood as a orthogonal, non-business aspect) and made the code a lot less readable than before. To the point where lots of i18n was littered through Swing, display, logging and error code and the original business code was not understandable anymore.

With $ and _ as method names, the i18n part of the code fades away and no longer blocks the view to the really important code, the business one.

But of course I would strongly regiment the usage of static imports in my projects and control the code with checkers or reviews. The same goes for $ and _ as or in method names. As always, don’t be ideological, but use the best tools for the job. And if the best tool is $ as a method name, then you should use it I think. For people who can’t live with $() or _(), Messages still supports Messages.format().

@Tom: Yes. In projects there should be a i18n guide with i18n guidelines for keys, words, wording, grammar and style. And the guide should explain how i18n is done, so the developers know what $() means. For reading code from other projects (open source) the IDE helps as you said.