Exile on Keyboard St. - Blog sur Linux et Debian

Aller au contenu | Aller au menu | Aller à la recherche

Tag - Développement logiciel

Fil des billets - Fil des commentaires

mercredi 10 octobre 2018

Des logs claires et utiles en Java

L'utilisateur final d'un logiciel est toujours heureux lorsque ce logiciel produit des logs claires et utiles.

Malheureusement, les développeurs ne font pas toujours suffisamment le nécessaire pour:

  • Ajouter des logs et traces là ou c'est utile
  • Mettre ces logs dans le bon niveau de log
  • Les mettre à jour quand besoin est
  • Faire en sorte que ces logs ne pénalisent pas trop les performances du logiciel

Et pourtant, la deuxième plus grande catégorie d'utilisateurs d'un logicel, c'est .... l'équipe de développement de ce logiciel !!!

On va donc faire un tour des erreurs les plus communément faites en matière de logs, et ce dans le but de s'amélirorer !

1. Pas de logs du tout

La première erreur que je vois trop souvent, c'est l'absence complète de logs dans une méthode ou même dans un composant tout entier. Il est donc impossible en cas de doute(s) sur le fonctionnement de ce code, de savoir ce qu'il se passe, à part se connecter en debug sur le serveur, ce qui n'est évidemment pas possible chez un client.

2. Des logs uniquement en TRACE ou en FINEST

Deuxième erreur trop souvent commise, on a des logs mais seulement dans le niveau de log maximum !

Comme en pratique, il est déconseillé de configurer un logiciel avec un niveau de log maximum, il en résulte que ces logs ne sortiront la plupart du temps pas chez les clients.

Ce cas arrive souvent quand le développeur veut mettre des logs mais il n'est pas certain du niveau de logs qu'il faut choisir. Et comme il développe avec un niveau de log en TRACE, ses logs s'affichent et il est content !

3. Des logs sans suffisamment de contexte

C'est moins fréquent, mais j'ai aussi vu des logs qui ressemblent à ça:

LOGGER.log(Level.INFO, "Creating user");

ou

LOGGER.log(Level.INFO, "Entering method 'needsRestart'");

Des logs comme celles-cis ne donnant aucun contexte, elles ne sont pas vraiment utiles.

Il s'agit en fait de traces utilisées lors du développement ou plus précisément du debug et qui auraient dù être enlevées ensuite.

4. Des logs avec une chaîne de formatage fausse

Le cas le plus courant de chaîne de formatage fausse est l'erreur sur le nombre de paramètres, par exemple:

LOGGER.info("Computing user: {} identifier: {}", user.getName());

Manifestement, il va nous manquer une information dans la log ...

Si à la place on avait:

LOGGER.info("Computing user: {} identifier: {}", getParam("user"), getParam("identifier"), getParam("extra"));

La méthode getParam serait appelée trois fois alors que le troisième paramètre n'est pas utilisé. Cela nous amènera à utiliser un Supplier et les méthodes lambdas avec Java 8.

5. Des logs faites par des anciens développeurs C

Dans les logs en Java, on trouve aussi le résultat de la programmation en C: le développeur Java qui met des String.format(...) partout !

LOGGER.info(String.format("Computing user: %s identifier: %s", getParam("user"), getParam("identifier")));

Ce qui va formater la chaîne même si le niveau de log ne permet pas que le message s'affiche. On en revient aux Suppliers.

Ensuite il est inutile de recourir à String.format(....) puisque Log4j ou java.util.logging formattent très bien le message en convertissant tout en chaînes de caractères.

Parfois le String.format(...) est tout simplement oublié:

LOGGER.info("Computing user: %s identifier: %s", getParam("user"), getParam("identifier"));

Ce qui affiche quelque chose comme:

06:48:36.094 main INFO org.grumpyf0x48.test.Log4j2Test - Computing user: %s identifier: %s

ce qui n'était probablement pas souhaité !

6. Des logs avec des passages de paramètres .... illisibles

On voit aussi des développeurs qui veulent logger beaucoup de choses dans le même message, et qui ont la hantise du plantage, et qui donc non content de passer 8 paramètres au message de log (et ce tout sur la même ligne temps qu'à faire), font une vérification pour chacun (ou presque) comme: (name == null) ? "no name supplied" : name.

C'est parfaitement inutile puisque dans ce cas Log4J affichera simplement "null" sans se planter. En outre ce genre de message compliqué est difficile à lire et à maintenir, donc à bannir.

Voilà, j'imagine qu'il y a des cas d'erreurs que j'oublie, n'hésitez pas à faire un commentaire si c'est le cas.

dimanche 15 avril 2018

Rechercher rapidement dans le code source avec ack

Rechercher dans du code source est une des activités principales du développeur.

Dans les logiciels aux architectures incertaines et maintenant avec la "méthode" Agile, il est souvent diffcile de savoir rapidement ou est gérée telle ou telle fonctionnalité dans le code.

Pendant longtemps, rechecher dans le code ressemblait à ça:

find . -name "*.java" -exec grep HashMap {} \; -print

Certains me diront:

Bahhhhh, Qu'est-ce que c'est compliqué ?

Où encore l'excuse qui n'en est pas une:

Mais moi je suis sous Windows ...

Heureusement, il existe maintenant des outils plus rapides à l'usage que les commandes find et grep combinées.

J'ai découvert il y a quelques années la commande ack-grep ou ack qui est précisément faites pour notre besoin: chercher des motifs dans une base de code.

Je vous passe ici l'installation d'ack: ack est un script Perl qui s'installe très simplement ; évitez le package de votre distribution afin d'avoir la version la plus récente.

Maintenant, notre commande précédente s'écrit comme suit:

ack --java HashMap

C'est quand même plus court !

J'ai précisé à la commande que je voulais chercher dans des sources Java. Dans types de fichiers sont prédéfinis dans ack:

 ack --help-types
Usage: ack [OPTION]... PATTERN [FILES OR DIRECTORIES]

The following is the list of filetypes supported by ack.  You can
specify a file type with the --type=TYPE format, or the --TYPE
format.  For example, both --type=perl and --perl work.

Note that some extensions may appear in multiple types.  For example,
.pod files are both Perl and Parrot.

    --[no]actionscript .as .mxml
    --[no]ada          .ada .adb .ads
    --[no]asm          .asm .s
    --[no]asp          .asp
    --[no]aspx         .master .ascx .asmx .aspx .svc
    --[no]batch        .bat .cmd
    --[no]cc           .c .h .xs
    --[no]cfmx         .cfc .cfm .cfml
    --[no]clojure      .clj
    --[no]cmake        CMakeLists.txt; .cmake

Si vous utilisez un type de fichier non connu d'ack, vous pouvez le définir.

Ensuite, de nombreuses options de la commandes ack sont reprises de celles de grep:

       -i, --ignore-case
           Ignore case distinctions in PATTERN
       -v, --invert-match
           Invert match: select non-matching lines

ou les classiques:

       -l, --files-with-matches
           Only print the filenames of matching files, instead of the matching text.

       -L, --files-without-matches
           Only print the filenames of files that do NOT match.

ack permet comme grep d'afficher les lignes de contexte autour du motif trouvé:

       -A NUM, --after-context=NUM
           Print NUM lines of trailing context after matching lines.

       -B NUM, --before-context=NUM
           Print NUM lines of leading context before matching lines.

ce qui facilite la lisibilité de la sortie.

Par défaut, ack va parcourir tous les sous-répertoires du répertoire courant. Ce comportement peut-être changé par:

       -r, -R, --recurse
           Recurse into sub-directories. This is the default and just here for compatibility with grep. You can also use it for
           turning --no-recurse off.

Enfin, ack peut utiliser un fichier de configuration ~/.ackrc.

Pour créer celui utilisant les options par défaut:

ack --create-ackrc > ~/.ackrc

dimanche 29 octobre 2017

IntelliJ IDEA: Quel formatage pour votre code Java

Beaucoup de développeurs, même expérimentés, ne prêtent pas (ou pas assez) attention au formatage du code.

Pourtant, l'utilisation d'un template de formatage de code présente les entre autres les avantages suivants:

  • le code est plus facile à lire
  • Les lignes blanches successives et inutiles sont évitées
  • En Java, le pavé des imports sera toujours cohérent entre les développeurs
  • Il permet de voir facilement les blocs, même ceux ne contenant qu'une instruction
  • Une fois un template de formatage choisi dans une équipe, les conflits à l'update sont évités et les merges facilités

Malheureusement, la plupart des projets de développement n'imposent pas un template de formatage et les développeurs se contentent trop souvent du template par défaut de leur environnement de développement. Et comme tous les développeurs n'utilisent pas le même IDE ...

Eclipse propose par exemple trois templates par défaut, qui tous utilisent des tabulations pour indenter le code ... Pire, le profile "Java Conventions" utilise à la fois des tabulations et des espaces. C'est bien dommage qu'Eclipse propose de formater le code avec des tabulations, ce que très peu de gens font encore. Parait t'il qu'historiquement, ce choix avait pour but de "sauver" de l'espace disque !!! Cette époque là est bien révolue. Enfin, pour modifier la façon de formater le code par défaut d'Eclipse, il faut dupliquer le profile avant de pouvoir le modifier, ce qui n'est pas très commode. IntelliJ IDEA n'impose pas cette restriction.

Dans ce billet, on va quand même dupliquer le profile par défaut d'IntelliJ, pour pouvoir exporter nos paramètres et aussi revenir facilement au profile par défaut.

Interdire la détection de l'indentation existante

Première chose à faire dans IntelliJ IDEA, décocher la case "Detect and use existing file indents for editing". En effet, avec cette option, si un fichier est indenté avec des tabulations, IntelliJ considèrera qu'il faut continuer d'indenter de cette façon !!!

Utiliser EditorConfig ou pas ?

EditorConfig est un format de fichier texte permettant de définir des profiles de formatage de code, via quelques propriétés. Ce format est censé être supporté par de nombreux éditeurs, ce qui est très séduisant. Malheureusement, trop peu de propriétés sont implémentées par exemple par le plugin EditorConfig pour IntelliJ, et on est donc amené à définir le reste du paramétrage dans la configuration standard de l'éditeur. J'y reviendrai peut être dans un billet séparé. Pour l'instant, on va cocher qu'on n'utilise pas EditorConfig.

Onglet 'Tabs and Indents'

On ne change rien dans cette section puisqu'IntelliJ utilise par défaut les espaces pour l'indentation et 4 de plus à chaque bloc. Ce formatage nous convient.

Onglet 'Spaces'

Dans cette section, on va cocher dans la sous-section 'Within' la case 'Array initializer braces', ce qui permet de mieux voir les paramètres dans les appels à log4j ou java.util.logging.

Onglet 'Wrapping and braces'

C'est dans cette section que l'on va modifier le plus de choses.

Concernant la position des accolades, on va adopter le style Allman, c'est à dire positionner les accolades sur la ligne suivante.

Toutes les valeurs de la sous section 'Braces placement' seront donc positionnées à 'Next line'.

Une fois qu'on a fait cela, il est logique:

  • dans 'if() statement' de cocher 'else on new line'
  • dans 'try statement' de cocher 'catch on new line' et 'finally on new line'
  • dans 'do while statement' de cocher 'while on new line'

Enfin, afin que les blocs soient bien visibles, même ceux ne contenant qu'une instruction, on va position à 'always' les propriétés 'Force braces' des sous-sections suivantes:

  • 'if() statement'
  • 'for() statement'
  • 'while() statement'
  • 'do while() statement'

Onglet 'Blank lines'

Dans la sous-section 'Keep maximum blank lines', on positionnera les 3 propriétés suivantes à 1 au lieu de 2:

  • In declarations:
  • In code:
  • Before '{':

En effet, je trouve que trop de lignes blanches n'aide pas à la lisibilité mais nous oblige à scroller.

Onglets 'JavaDoc', 'Imports' et 'Arrangement'

Je ne modifie rien pour l'instant.

Onglet 'Code generation'

Dans la section 'Final modifier' on coche les deux cases:

  • Make generated local variables final
  • Make generated parameters final

Vous pouvez utiliser le Formateur de code Java pour IDEA défini ci-dessous en le téléchargeant avec le lien précédent.