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 14 août 2019

10 raccourcis clavier indispensables dans IDEA

Les développeurs Java connaissent bien les raccourcis clavier les plus usuels d'IntelliJ IDEA comme par exemple:

  • Shift Shift: Search everywhere
  • Alt + Enter: Show intentions
  • Shift + F6: Rename

ou encore:

  • Alt + Ins (ou Fn + Alt + Suppr): Generate code

Mais il y en a bien d'autres que nous utilisons quotidiennement, et ce sont ceux-la qui nous intéressent aujourd'hui.

Ctrl + Shift + A permet de chercher directement une action sans avoir à parcourir la barre d'outils ou l'ensemble des menus.

Ctrl + N, Ctrl + Alt + Shift +N permet de chercher respectivement une classe ou un symbole (variable, méthode ...).

Les deux raccourcis précédents sont des "spécialisations" du menu principal de recherche auquel on accède par Shift Shift.

Seul regret, les raccourcis utilisant 4 touches comme Ctrl + Alt + Shift + N sont un peu fatiguants à la longue !

Ctrl + F12 affiche le popup "File structure", ce qui pour une classe affiche l'ensemble des champs et méthodes. Avec Eclipse, le raccourci était Ctrl + O, mais vous n'utilisez plus Eclipse depuis longtemps !!!

Un raccourci que j'utilise souvent pour naviguer au sein de l'ensemble des fichiers actuellement modifiés, c'est Ctrl + Alt + Left / Right, et ça rend la navigation plus simple que de cliquer chaque fois sur l'onglet du fichier suivant.

Dans la même veine Ctrl + E et Ctrl + Shift + E affichent le "Recent files / Recent locations" popup. Ctrl + E affiche les fichiers récemment ouverts et Ctrl + Shift + E les endroits précis de ces fichiers récemment ouverts.

Ces deux racourcis sont extrèmement commodes surtout qu'en cliquant sur "Show changed only", on peut restreindre les résultats aux seules modifications faites dans le code.

Toujours dans la catégorie Navigation, F2, Shift F2 permettent de naviguer vers la prochaine / précédente erreur dans le fichier courant. Cela va infiniment plus vite que d'aller cliquer sur la petite ligne rouge dans la scrollbar ! Par contre, c'est un peu dommage qu'on ne puisse pas passer d'un fichier à l'autre - quand on a plusieurs erreurs de compilation suite à un changement de signature par exemple, ce serait bien pratique.

Pour ceux qui font du TDD, Ctrl + Shift + T permet de créer un classe de test pour la classe courante, ou de naviguer vers celle-ci si elle existe, ou encore de revenir à la classe d'implémentation depuis la classe de test. C'est alors très rapide de voir qu'une classe ne comporte pas de test unitaire ...

Curieusement, ce raccourci semble ne pas figurer dans la ReferenceCard des raccourcis d'IDEA !

Ctrl + Alt + Maj + T est un de mes préférés, il affiche le menu contextuel "Refactor this", et vous évite de mémoriser tous les racourcis correspondants: Extract variable, Extract method ...

L'avant dernier, Ctrl + Maj + Up / Down déplace le bloc de code sélectionné, c'est toujours plus propre et moins casse gueule que le Copier / Coller.

Enfin, le dernier Ctrl + Alt + Shift + S accède aux propriétés du projet, c'est à dire la fenêtre "File structure", dans lequel on choisit notamment le JDK utilisé.

dimanche 17 mars 2019

Faire cohabiter les raccourcis clavier de Linux avec ceux d'IDEA

Les raccourcis clavier permettent de gagner un temps précieux quand on les connait bien, mais encore faut-il que ceux définis par le logiciel qu'on utilise n'entrent pas en conflit avec ceux du système.

L'IDE de développement de JetBrains, IDEA, permet d'utiliser plusieurs KeyMap:

  • Default
  • Default for GNOME
  • Default for KDE
  • ...

On utilisera ici 'Default for GNOME'.

Parmi les raccourcis clavier les plus utilisés dans IDEA, on trouve:

  • Ctrl + Alt + Left: Navigate back
  • Ctrl + Alt + Right: Navigate forward

Malheureusement ces raccourcis sont déjà définis par Linux pour passer d'un espace de travail à un autre.

De même les racourcis clavier suivants d'IntelliJ IDEA:

  • Alt + F7: Find usages
  • Ctrl + Alt + L: Reformat code
  • Alt + F8: Evaluate expression

sont utilisés respectivement par Linux pour les actions suivantes:

  • Move window
  • Lock screen
  • Resize window

Comme je passe le plus clair de mon temps avec IDEA, j'ai changé les raccourcis Linux cités ci-dessus en leur ajoutant la touche Shift, ce qui donne par exemple:

  • Ctrl + Alt + Shift + L: Lock screen

Cela fait certes un peu de gymnastique avant d'aller déjeuner, mais au moins je n'ai pas changé la configuration d'IDEA.

Mais ce n'est pas fini !

Le raccourci Ctrl + Alt +T qui permet de lancer un Terminal sous Linux est aussi défini par IDEA. Je désactive donc le raccourci d'IDEA que ne n'utilise pas.

Un autre. IDEA définit Ctrl + E pour accéder à la liste des fichiers récents. Mais ce raccourci permet aussi d'aller à la fin de la ligne dans une session Bash !!! Donc si vous ouvrez un Terminal dans IntelliJ, Ctrl + E affiche les fichiers récents au lieu d'aller à la fin de la ligne de commande. Pour celui-ci, j'ajoute Shift sur le raccourci d'IDEA.

Un dernier, et qui n'a rien à voir avec IDEA, c'est Alt + F, qui permet d'avancer d'un mot en Bash, se trouve désactivé par défaut par la configuration du menu fichier de la fenête des Terminaux Mate. Je modifie donc ce paramètre pour pouvoir utiliser pleinement les raccourcis Bash:

Capture-Raccourcis_clavier.png

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.

- page 1 de 2