Accueil > Non classé > Un peu de LOLcode…

Un peu de LOLcode…

Introduction

Dans cet article, je vous propose quelque chose d’assez différent des sujets abordés habituellement. En lisant du code écrit par d’autres développeurs, je suis resté perplexe sur quelques méthodes. Après les avoir relues quelques fois, la façon d’écrire m’a fait sourire, comme quoi d’un développeur à l’autre les méthodes de réflexion et d’écriture de code varient fortement.

Je vous propose donc quelques extraits de code méritant le détour, ça donne des snippets assez drôles, cherchez l’erreur !

Continue comme ça


1
2
3
4
5
6
7
for (Object i : list) {
  if (condition) {
    doSomeStuff(someArguments);
    continue;
  }
  doSomeStuff(someOtherArguments);
}

continue, what else? (ce jeu de mots est © Pierre-Yves Ricau)

Tu peux pas test

Contexte : imaginez une méthode initialize(java.util.Properties) qui s’attend à la présence d’une propriété MY_PROPERTY pour l’utiliser lors de l’initialisation d’un objet :


1
2
3
4
5
public void initialize(Properties props) {
  if (props.getProperty(MY_PROPERTY)) {
    // ici on utilise cette propriété...
  }
}

Le test unitaire est tout naturellement :


1
2
3
4
5
6
  public void testNullProperty(){
    Properties properties = new Properties();
    assertNotNull(properties);
    assertNull("property must be null", properties.getProperty(MY_PROPERTY));
    myClassInstance.initialize(properties);
  }

Pour résumer, on teste si une instance fraichement créée est non-nulle, tout en vérifiant qu’elle ne contient pas encore la propriété… Quant à la méthode initialize() qui est censée faire l’objet du test, certes on l’appelle mais on ne fait aucune vérification dessus. Bon, après tout le test passe, c’est le principal non ?
Ce test n’est d’ailleurs pas isolé, plusieurs autres tests vérifient de la même façon la non-présence dans properties d’autres propriétés utilisées dans initialize() :-D.

Double fail inversé


1
myVar = (myMap != null) ? "" : myMap.get(myField);

Non seulement on n’a pas la valeur attendue, mais en plus on aura forcément une NullPointerException si myMap vaut null :D.

True or false?


1
2
3
4
5
public boolean superComplexLogic(boolean value) {
    boolean ret= false;
    if((getValue2() && value) || (!getValue2() && !value)) ret=true;
    return ret;
}

Pourquoi faire simple ? Un return (getValue2() == value); aurait été tellement banal !

TODO != Tout doux


1
2
3
4
// TODO en lot 8
if ("TODO".equals("TODO1")) {
  // ...
}

Sympathique cette façon d’éviter que du code soit executé, non ? :-P

100% de couverture de tests !


1
2
3
4
5
6
7
8
9
10
public enum MyEnum {
    MY_CONSTANT("O"),
    //...
}

// Et le test associé :
@Test
public void testMyConstant() {
    assertEquals("O", MyEnum.MY_CONSTANT);
}

Au moins, si on fait une faute de frappe en écrivant l’enum, ce test le verra tout de suite ;-)

L’opération a échoué avec succès !


1
2
//succes - Recuperer la liste à réemettre.
logger.logError(ServiceLogKeys.SUCCESS_CODE);

Conclusion

J’espère que ce petit moment de détente vous a plus, si c’est le cas nous allons essayer de motiver les troupes d’Excilys pour publier des articles collaboratifs de ce genre de temps en temps. Si vous avez aussi des exemples de LOLcode, n’hésitez pas à vous lacher dans les comms (attention aux clauses de non divulgation tout de même) ;-).

Share
Categories: Non classé Tags: , , ,