blog:sikovne_sablony_pro_eclipse [Lukáš Zapletal]

Šikovné šablony pro Eclipse

Výbornou funkcí Eclipse IDE jsou šablony – templates. Několik jich je nadefinováno, ale hlavní síla je v tom, že se uživatel může definovat svoje. Používají se jednoduše, například šablonu System.out.println(…); vyvoláte napsáním syso a stiskem Ctrl+Space. Vlastní šablony pak můžete definovat v Preferences (dejte do vyhledávacího pole „templates“ abyste našli správné podokno s nastavením). Několik příkladů:

Logger SLF4J

Ve většině projektů loguji pomocí knihovny SLF4J. Tato šablona vloží nutný kód do každé třídy

Co vytvoří:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
 
final Logger logger = LoggerFactory.getLogger(MyClass.class);

Šablona:

final Logger logger = LoggerFactory.getLogger(${enclosing_type}.class);
${imp:import(org.slf4j.Logger,org.slf4j.LoggerFactory)}
${cursor}

Pokud používáte starší verzi Eclipse, která neumí proměnnou imp:import, můžete šablonu nadefinovat takto: final org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger(${enclosing_type}.class);. U příštího Optimize imports se importy vloží na správné místo.

Check argument

Šablona pro otestování, zda argument funkce není null. Vytvoří:

if (param == null) {
  throw new IllegalArgumentException("Method com.pike.x.y.MyClass.myMethod does not expect null parameter");
}
 
// pro více parametrů
if (param1, param2 == null) {
  throw new IllegalArgumentException("Method com.pike.x.y.MyClass.myMethod does not expect null parameter");
}

Nevýhodou je, že pro více parametrů je nutné poeditovat if-výraz. Pořád ale ušetřím spoustu času psaním „throw new“ řádku, protože tato podmínka je nesmírně důležitá. Šablona je:

if (${enclosing_method_arguments} == null) {
	throw new IllegalArgumentException("Method ${enclosing_package}.${enclosing_type}.${enclosing_method} does not expect null parameter");
}
${cursor}

To je prozatím vše. Doporučuji projít si předdefinované šablony (for, foreach, …) – je jich mnoho.

java

Diskuze

Jindra, 2008/10/23 17:31

to s importem je krasna vec ktera mi doted chybela, bohuzel v eclipse 3.3.2 nefunguje :-( dalsi duvod prejit na novejsi verzi :-)

benzin, 2008/10/23 18:13

Ano to je super, stejne tak jako psani pomoci hohole logu, nebo UnsuportedOperation atd.

Ale konkretne v tomto pripade je lepsi pouzit assert a jeste lepsi nejaky contractovaci tool.

jira, 2008/10/23 23:04

A jaký kontraktovací tool je dobrý?

benzin, 2008/10/24 08:04

Mne osobne se docela libi contract4j a pouzivam ho i proto ze pouzivam CTW, takze to skutecne muzu pouzit ve vsech tridach. Jinak existuje i contract for spring, ktery ale funguje jenom u managovanych bean.

Lukáš Zapletal, 2008/10/24 08:07

Někde jsem četl, že se assert nemá používat pro testování prekondicí metod, a to proto, že assert se dá u release verze odstranit, ale prekondice se musejí testovat vždy (tedy i v „ostré“ verzi produktu). Něco na tom je, proto používám tento způsob.

benzin, 2008/10/25 10:01

4Lukaz Zapletal: Nemyslim si, ze prekondice je nutne testovat i v ostre verzi. Prekondice, ktere sou zde predstaveny sou jen pro lazeni. A k tomu presne je assert, paklize chcete v ostrem behu mit moznost ziskat ladici vystup, pak nebudete vypinat asserty. Vypnutim assertu rikate, ze chcete maximalni rychlost i kdyz budou chybove stavy tezce laditelne.

K cemu jinemu by tedy byly asserty vubec vhodne?

Ladislav Thon, 2008/10/26 23:06

Proboha, co to jsou ty „prekondice“? ;-)

Jinak vhodný způsob (myslím, že ho doporučuje i Josh Bloch v Effective Java) je „ručně“ testovat hodnoty a vyhazovat výjimky v případě metod volaných zvenčí, a asserty použít pro metody soukromé, kde špatný parametr je chybou programátora.

Lukáš Zapletal, 2008/10/30 09:09

Benzin: určitě je nutné testovat prekondice (uznávám - šílený výraz) i v ostré verzi! Některé hůře navržené metody například mohou při určitém (špatném) vstupu uživatele vrátit null a tato hodnota se pošle jako parametr do jiné metody. Kdyby to byla release bez assertů, tak bych dřív nebo později vykoukla na uživatele NPE. Z tohoto jednoduchého příkladu jasně vyplývá, že assert není vhodný, což potvrzuje i J. Bloch ve svém životním díle Effective Java, jak píše Ladislav.