La recherche utile Eclipse Java modèles de code

Certains autres modèles ici: Lien Que J'Ai -
Lien II

J'aime celui-ci:

readfile

 ${:import(java.io.BufferedReader,  
           java.io.FileNotFoundException,  
           java.io.FileReader,  
           java.io.IOException)}  
 BufferedReader in = null;  
 try {  
    in = new BufferedReader(new FileReader(${fileName}));  
    String line;  
    while ((line = in.readLine()) != null) {  
       ${process}  
    }  
 }  
 catch (FileNotFoundException e) {  
    logger.error(e) ;  
 }  
 catch (IOException e) {  
    logger.error(e) ;  
 } finally {  
    if(in != null) in.close();  
 }  
 ${cursor} 

Mise à JOUR: La Java version 7 de ce modèle est:

${:import(java.nio.file.Files,
          java.nio.file.Paths,
          java.nio.charset.Charset,
          java.io.IOException,
          java.io.BufferedReader)}
try (BufferedReader in = Files.newBufferedReader(Paths.get(${fileName:var(String)}),
                                                 Charset.forName("UTF-8"))) {
    String line = null;
    while ((line = in.readLine()) != null) {
        ${cursor}
    }
} catch (IOException e) {
    //${todo}: handle exception
}

Je sais que je suis coups de pied morte post, mais je voulais partager ce pour l'achèvement souci:

Une version correcte de singleton modèle de génération, qui permet de surmonter les défauts de double-vérifier la conception de verrouillage (discuté ci-dessus et mentionné ailleurs)

Singleton Modèle De Création:
Le nom de cette createsingleton

static enum Singleton {
    INSTANCE;

    private static final ${enclosing_type} singleton = new ${enclosing_type}();

    public ${enclosing_type} getSingleton() {
        return singleton;
    }
}
${cursor}

Pour accéder à des singletons généré à l'aide ci-dessus:

Singleton Modèle de référence:
Le nom de cette getsingleton:

${type} ${newName} = ${type}.Singleton.INSTANCE.getSingleton();

Pour log, une petite comptine de l'ajouter dans la variable membre.

private static Log log = LogFactory.getLog(${enclosing_type}.class);

Null Contrôles De!

if( ${word_selection} != null ){
    ${cursor}
}

if( ${word_selection} == null ){
    ${cursor}
}

Une petite astuce sur sysout -- j'aime renommé "sop". Rien d'autre dans la libs java commence avec la "concession" de sorte que vous pouvez rapidement de type "concession", et boum, il s'insère.

Rien de compliqué pour le code de la production - mais très utile pour les révisions du code

J'ai mon modèle coderev low/med/high, procédez de la manière suivante

/**
 * Code Review: Low Importance
 * 
 *
 * TODO: Insert problem with code here 
 *
 */

Puis dans l'affichage des Tâches - me montrera tous de la révision du code des commentaires, je voudrais mettre en place au cours d'une réunion.

slf4j Journalisation

${imp:import(org.slf4j.Logger,org.slf4j.LoggerFactory)}

private static final Logger LOGGER = LoggerFactory
    .getLogger(${enclosing_type}.class);

Post Java 7, une excellente façon de configurer les enregistreurs de besoin (ou si vous préférez) références statiques de la classe englobante est d'utiliser le nouvellement introduit MethodHandles API pour obtenir la classe d'exécution dans un contexte statique.

Un exemple extrait de SLF4J est:

private static final Logger logger = LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());

En plus d'être un simple extrait de code dans les IDE, il est aussi moins fragiles si vous refactoriser un certain nombre de fonctionnalités dans une autre classe parce que vous n'aurez pas accidentellement porter le nom de la classe avec elle.

Lors de l'essai de autour de avec code que j'ai parfois manqué de suppression de certains syso s. Donc, je me suis fait un modèle appelé syt.

System.out.println(${word_selection}${});//${todo}:remove${cursor}

Avant que je compile je vérifie toujours mes TODOs et ne jamais oublier de supprimer un Système.de nouveau.

Obtenir une SWT couleur de l'affichage actuel:

Display.getCurrent().getSystemColor(SWT.COLOR_${cursor})

Suround avec syncexec

PlatformUI.getWorkbench().getDisplay().syncExec(new Runnable(){
    public void run(){
        ${line_selection}${cursor}
    }
});

Utiliser le modèle de conception singleton:

/**
 * The shared instance.
 */
private static ${enclosing_type} instance = new ${enclosing_type}();

/**
 * Private constructor.
 */
private ${enclosing_type}() {
    super();
}

/**
 * Returns this shared instance.
 *
 * @returns The shared instance
 */
public static ${enclosing_type} getInstance() {
    return instance;
}

Le modèle de l'enregistreur de déclaration est grande.

J'ai aussi créer linfo, ldebug, lwarn, lerror pour les niveaux de journal que j'utilise le plus souvent.

lerror:

logger.error(${word_selection}${});${cursor}

Insérer les méthodes d'analyse devraient-donné-quand-alors

J'ai vu une version similaire à celui récemment, tandis que la programmation en binôme avec un très bon développeur et ami, et je pense que ça pourrait être une belle addition à cette liste.

Ce modèle permettra de créer une nouvelle méthode d'essai à une classe, à la suite de la Compte tenu de Quand Puis approche de la behavior-driven development (BDD) de paradigme sur les commentaires, comme guide pour structurer le code. Il va commencer le nom de la méthode avec "devrait" et vous permettent de remplacer le reste de la tétine, le nom de la méthode "CheckThisAndThat" avec la meilleure description possible de la méthode d'essai de la responsabilité. Après le remplissage, le nom de l'ONGLET, vous mènera directement à la //Given section, de sorte que vous pouvez commencer à taper vos conditions préalables.

Je l'ai mappé les trois lettres "tst", avec la description "méthodes d'Essai devrait-donné-si-alors" 😉

J'espère que vous la trouverez utile comme je l'ai fait quand je l'ai vu:

@Test
public void should${CheckThisAndThat}() {
    Assert.fail("Not yet implemented");
    //Given
    ${cursor}

    //When


    //Then

}${:import(org.junit.Test, org.junit.Assert)}

Ici est un constructeur de non-classes instanciables:

//Suppress default constructor for noninstantiability
@SuppressWarnings("unused")
private ${enclosing_type}() {
    throw new AssertionError();
}

C'est un custom exceptions:

/**
 * ${cursor}TODO Auto-generated Exception
 */
public class ${Name}Exception extends Exception {
    /**
     * TODO Auto-generated Default Serial Version UID
     */
    private static final long serialVersionUID = 1L;    

    /**
     * @see Exception#Exception()
     */
    public ${Name}Exception() {
        super();
    }

    /**
     * @see Exception#Exception(String) 
     */
    public ${Name}Exception(String message) {
        super(message);         
    }

    /**
     * @see Exception#Exception(Throwable)
     */
    public ${Name}Exception(Throwable cause) {
        super(cause);           
    }

    /**
     * @see Exception#Exception(String, Throwable)
     */
    public ${Name}Exception(String message, Throwable cause) {
        super(message, cause);
    }
}

J'ai eu beaucoup de l'utilisation de ces extraits, à la recherche de null valeurs et des chaînes vides.

- Je utiliser l'argument de "test"-modèles comme le premier code dans mes méthodes de vérification a reçu des arguments.

testNullArgument

if (${varName} == null) {
    throw new NullPointerException(
        "Illegal argument. The argument cannot be null: ${varName}");
}

Vous pouvez modifier le message d'exception pour s'adapter à votre entreprise ou d'un projet standard. Cependant, je ne recommande d'avoir un message qui contient le nom de la délinquance argument. Sinon l'appelant de votre méthode aura de regarder dans le code pour comprendre ce qui s'est passé. (Un NullPointerException avec aucun message produit une exception avec le assez absurde message "null").

testNullOrEmptyStringArgument

if (${varName} == null) {
    throw new NullPointerException(
        "Illegal argument. The argument cannot be null: ${varName}");
}
${varName} = ${varName}.trim();
if (${varName}.isEmpty()) {
    throw new IllegalArgumentException(
        "Illegal argument. The argument cannot be an empty string: ${varName}");
}

Vous pouvez également réutiliser le nul de la vérification de modèle à partir de ci-dessus et de mettre en œuvre cet extrait de code pour vérifier uniquement pour les cordes à vide. Vous pouvez alors utiliser ces deux modèles pour produire le code ci-dessus.

Le modèle ci-dessus, cependant, le problème est que si l'argument est définitive, vous devrez modifier le code produit certains (la ${varName} = ${varName}.trim() échouera).

Si vous utilisez beaucoup de finale arguments et que vous souhaitez vérifier pour les cordes à vide, mais n'a pas de garniture comme une partie de votre code, vous pourriez aller avec ceci à la place:

if (${varName} == null) {
    throw new NullPointerException(
        "Illegal argument. The argument cannot be null: ${varName}");
}
if (${varName}.trim().isEmpty()) {
    throw new IllegalArgumentException(
        "Illegal argument. The argument cannot be an empty string: ${varName}");
}

testNullFieldState

J'ai également créé quelques extraits pour le contrôle des variables qui n'est pas envoyé comme arguments (la grande différence est le type d'exception, étant désormais une IllegalStateException à la place).

if (${varName} == null) {
    throw new IllegalStateException(
        "Illegal state. The variable or class field cannot be null: ${varName}");
}

testNullOrEmptyStringFieldState

if (${varName} == null) {
    throw new IllegalStateException(
        "Illegal state. The variable or class field cannot be null: ${varName}");
}
${varName} = ${varName}.trim();
if (${varName}.isEmpty()) {
    throw new IllegalStateException(
        "Illegal state. The variable or class field " +
            "cannot be an empty string: ${varName}");
}

testArgument

C'est un modèle général pour le test d'une variable. Il m'a fallu quelques années pour vraiment apprendre à apprécier celui-ci, maintenant je l'utilise beaucoup (en combinaison avec les modèles ci-dessus, bien sûr!)

if (!(${varName} ${testExpression})) {
    throw new IllegalArgumentException(
        "Illegal argument. The argument ${varName} (" + ${varName} + ") " +
        "did not pass the test: ${varName} ${testExpression}");
}

Vous entrez un nom de variable ou une condition qui renvoie une valeur, suivie par un opérande ("==", "<", ">", etc) et une autre valeur ou variable et, si le test échoue, le code résultant lèvera une IllegalArgumentException.

La raison pour laquelle le légèrement compliqué si la division, avec l'ensemble de l'expression enveloppé dans une "!()" est de rendre possible la réutilisation de la condition de test dans le message d'exception.

Peut-être qu'il va confondre un collègue, mais seulement si elles ont à regarder le code, qu'ils pourraient ne pas avoir à le faire, si vous jeter ces types d'exceptions...

Voici un exemple avec les tableaux:

public void copy(String[] from, String[] to) {
    if (!(from.length == to.length)) {
        throw new IllegalArgumentException(
                "Illegal argument. The argument from.length (" +
                            from.length + ") " +
                "did not pass the test: from.length == to.length");
    }
}

Vous obtenez ce résultat en appelant le modèle, en tapant "de.longueur" [TAB] "== pour.longueur".

Le résultat est plus drôle que d'une "exception ArrayIndexOutOfBoundsException" ou similaire, et peut en fait donner à vos utilisateurs une chance de comprendre le problème.

Profitez-en!

Mon préféré, quelques-uns sont...

1: Javadoc, à insérer le doc au sujet de la méthode d'un Printemps objet méthode d'injection.

 Method to set the <code>I${enclosing_type}</code> implementation that this class will use.
* 
* @param ${enclosing_method_arguments}<code>I${enclosing_type}</code> instance 

2: fenêtre de Débogage, pour créer un FileOutputStream et écrire la mémoire tampon du contenu d'un fichier.
Utilisé pour lorsque vous souhaitez comparer un tampon avec un passé run (en utilisant BeyondCompare), ou si vous ne pouvez pas afficher le contenu d'un tampon (via inspecter) parce que sa trop grande...

java.io.FileOutputStream fos = new java.io.FileOutputStream( new java.io.File("c:\\x.x"));
fos.write(buffer.toString().getBytes());
fos.flush();
fos.close();

Avec l'aide de plugin: http://code.google.com/p/eclipse-log-param/

Il est possible d'ajouter le modèle suivant:

logger.trace("${enclosing_method}. ${formatted_method_parameters});

Et obtenez le résultat:

public static void saveUserPreferences(String userName, String[] preferences) {
logger.trace("saveUserPreferences. userName: " + userName + " preferences: " + preferences);
}

- Je utiliser les modèles suivants pour le développement Android:

Verbose (Logv)

Log.v(TAG, ${word_selection}${});${cursor}

Debug (Logd)

Log.d(TAG, ${word_selection}${});${cursor}

Info (Logi)

Log.i(TAG, ${word_selection}${});${cursor}

Avertir (Logw)

Log.w(TAG, ${word_selection}${});${cursor}

Erreur (Loge)

Log.e(TAG, ${word_selection}${});${cursor}

Assert (Loga)

Log.a(TAG, ${word_selection}${});${cursor}

TAG est une Constante, que je définissent dans chaque activité.

Cela prend beaucoup de grunt travail d'impression et d'acquisition de valeurs locales. Il enregistre automatiquement le nom de la variable à l'intérieur d'une Chaîne. Cela permet d'économiser beaucoup de saisie et de correction faute de frappe.

Le modèle:

+ ", ${1:var}: " + ${1:var}

Il a deux écueils:

Bien que vous êtes invité à sélectionner un local /paramètre /champ, cela n'inclut pas les primitives(

Invites se produit chaque fois que le code est compilé sans erreurs. Souvent à l'aide de cette macro rendements temporairement rompu syntaxe, de sorte que certains de jonglerie est nécessaire d'insérer de multiples variables. Rien à proximité pour la commodité de ne pas avoir de fautes de frappe dans les noms de variable.

Section De Code

//--------------------------------------------------------------
//                      ${title}
//--------------------------------------------------------------
${cursor}

Utiliser ce modèle pour faire des commentaires sections de code plus facile. ce n'est pas très complexe, mais qui m'a sauvé beaucoup de temps 🙂

Créer un nouveau JUnit cas de test à partir de ce mot:

Cela nécessite un enregistreur (appelé _logger: il y a un très joli modèle pour que dans ce fil ainsi).

Je suis un grand fan de ce modèle, car il est très facile pour moi de créer des cas de test non implémentée rapidement la minute où je ne pense à eux. Ils vont s'asseoir il y a faute sur moi, comme un rappel de l'affaire, j'ai besoin de tester.

${:import(org.junit.Test, org.junit.Assert)}
@Test
public void fooTest() throws Throwable {
try {
${cursor}
Assert.fail("Not Implemented");
} catch (Throwable e) {
_logger.error("Failed test", e);
throw e;
}
}

Pour l'utiliser, tapez le nom du cas de test (dire testSerializeObject), mettez en surbrillance le mot, puis appuyez sur Ctrl + Espace (ou ce que vous avez configuré pour le code d'aider).

Mon modèle préféré pour un cas de test est celui qui enregistre les exceptions et ensuite renvoie d'eux, car j'aime voir les exceptions à la console plutôt que dans JUnit l'exception de l'observateur.

Si vous préférez Système.dans vos tests sur les fichiers journaux, vous pouvez toujours utiliser quelque chose de similaire comme:

${:import(org.junit.Test, org.junit.Assert)}
@Test
public void ${word_selection}() throws Exception {
try {
${cursor}
Assert.fail("Not Implemented");
} catch (Exception e) {
System.out.println("Failed test");
e.printStackTrace();
throw e;
}
}

list_methods - génère les méthodes d'ajout, de retrait, de comptage, et contient une liste

public void add${listname}(${listtype} toAdd){
get${listname}s().add(toAdd);
}
public void remove${listname}(${listtype} toRemove){
get${listname}s().remove(toRemove);
}
public ${listtype} get${listname}(int index){
return get${listname}s().get(index);
}
public int get${listname}Count(){
return get${listname}s().size();
}
public boolean contains${listname}(${listtype} toFind){
return get${listname}s().contains(toFind);
}
${cursor}

id - insère les annotations, les importations, le terrain, et les getter pour de simples JPA @Id

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
public Long getId(){
return id;
}
${cursor}
${:import (javax.persistence.GenerationType,javax.persistence.GeneratedValue,javax.persistence.Id)}

J'ai vu une réponse pour un modèle de création de base de la classe de test, et voici quelques appels individuels si vous préférez cette approche au lieu:

Créer le programme d'installation méthode avec @Avant l'importation

${:import(org.junit.Before)}
@Before
public final void setUp() {
${cursor}
}

Créer une nouvelle méthode d'essai avec @Test d'importation

${:import(org.junit.Test)}
@Test
public final void test${newName} () {
${cursor}
}

Je utiliser pour les aider avec JAXB les conversions entre les types et Otd:

Modèle pour la conversion de la variable à la valeur de retour de type (fonctionne avec le paramètre)

${return_type} ${name} = null;
if (${var} != null) {
${name} = new ${return_type}();
${cursor}
}
return ${name};

Une nouvelle méthode de test JUnit:

 @${testType:newType(org.junit.Test)}
public void ${testname}() throws Exception {
${staticImport:importStatic('org.junit.Assert.*')}${cursor}
String expected = "" ;
String actual = "" ;
Assert.assertEquals(expected, actual);
}