IntelliJ IDEA : style de code et formatage

Les outils modernes facilitent le processus de développement. En particulier, il est plus facile de surveiller le style de votre code, en essayant de minimiser son formatage « non autorisé ». Dans cette revue, je propose de vous familiariser avec les outils que l'IDE IntelliJ Idea fournit au développeur pour rendre le code agréable à lire et facile à comprendre.

Introduction

Un langage de programmation est très similaire au langage parlé par les gens. La seule différence est qu’il s’agit d’un langage spécial qui sert initialement à communiquer avec un ordinateur afin de lui expliquer ce que l’on attend de lui. Mais il ne peut y avoir de communication individuelle avec un ordinateur. Même lorsque vous avez commencé à apprendre un langage de programmation, vous avez consulté un livre ou une ressource pédagogique comme JavaRush. Et dans cette source, vous avez vu du code qu’un ordinateur comprendra. Mais vous devez également le comprendre à mesure que vous acquérez des connaissances sur le langage Java. Comme dans tout langage, la programmation comporte certaines règles pour former le code. Par exemple, écrire avec une clôture dans une société polie est considéré comme de mauvaises manières, et en Java, appeler une méthode avec une lettre majuscule est une violation flagrante du style de code. Les règles de formatage du code Java sont formulées dans le document Java Code Convention . De plus, le style de code peut réguler des détails plus petits, tels que l'indentation. Et lorsque des outils de contrôle de version sont utilisés, imaginez tout le cauchemar lorsque tout le monde enregistre un fichier soit en retrait sous forme d'onglet, soit en retrait sous forme d'espace. Qu'en sera-t-il pour quelqu'un qui a besoin de vérifier la modification avec une seule méthode, mais le fichier entier sera modifié en raison de la correction des espaces dans les tabulations ou vice versa. Naturellement, comme pour le langage ordinaire, le style peut varier selon l’endroit où il est utilisé. Par exemple, sur Internet, vous pouvez trouver Google Java Style Guide ou Twitter Java Style Guide . Pour cet article de synthèse, nous aurons besoin d’un sujet de test. Utilisons le service du système de construction de projet Gradle. Cela nous permettra de créer un nouveau projet à l'aide d'un modèle pour un démarrage rapide. Gradle a un excellent plugin : Build Init Plugin . Allons dans le nouveau répertoire et exécutons-y la commande : gradle init --type java-application Après cela, lancez IntelliJ Idea. Si vous voyez une fenêtre avec un projet déjà ouvert (vous verrez l'éditeur de code, l'arborescence du projet), fermez ce projet en utilisant File -< Close Project. Maintenant, dans la fenêtre de bienvenue, nous allons exécuter "Import Project"et importer notre nouveau projet. Lors de l'importation, définissez le drapeau "Use autoimport". Voyons s'il est possible de simplifier la vie d'une manière ou d'une autre à l'aide d'outils de développement modernes.

Formatage du code dans l'idée

Après avoir importé le projet, appuyez sur la combinaison de touches Ctrl+Net accédez à la classe AppTest. Cette classe est la classe de test par défaut. Cela ressemble à ceci :

import org.junit.Test;
import static org.junit.Assert.*;

public class AppTest {
    @Test public void testAppHasAGreeting() {
        App classUnderTest = new App();
        assertNotNull("app should have a greeting", classUnderTest.getGreeting());
    }
}

Qu’est-ce qui attire immédiatement votre attention ici ? Une annotation avec une déclaration de méthode sur une seule ligne, qui a l'air moche, d'accord. Comment régler ceci? IntelliJ Idea dispose d'une section de menu "Code"pour diverses manipulations de code. L'une de ces manipulations est "Reformat Code"une combinaison de touches Ctrl + L. Après application, l'annotation sera sur une ligne et la méthode elle-même sera sur une autre. Il convient de noter immédiatement que cette opération est effectuée sur une section de code sélectionnée . Et si rien de tel n’existe, l’opération de formatage sera effectuée sur tout le contenu. Ajoutons maintenant une nouvelle méthode de test :

@Test
public void testSummOfOddNumbers() {
	List<Integer> data = Arrays.asList(1, 4, 2, 3, 6, 7, 9);
	Integer result = data.stream().filter(number -> number % 2 == 0).reduce((n1, n2) -> n1 + n2).get();
	assertThat(result, is(12));
}

Et deux importations :

import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;

Comme vous pouvez le voir, l'opération sur Stream est placée sur une seule ligne. Mais que se passe-t-il si nous voulons nous assurer que les méthodes dont les appels sont chaînés sont toujours divisées en un point donné en nouvelles lignes ? D'une part, nous pouvons le faire manuellement. Mais rappelez-vous que nous voulons que tout fonctionne pour nous. Après tout, de temps en temps, nous oublierons et le format du code deviendra différent partout, et ce n'est pas bon. Il s'avère que vous devez modifier la règle selon laquelle Idea effectue le formatage. Sélectionnez l'élément Idée dans le menu File -> Settings(ou cliquez sur Ctrl + Alt + S). Dans le champ de recherche de la fenêtre des paramètres, écrivez « Style de code ». Dans la section Style de code, il est possible de spécifier des paramètres non seulement pour Java. Mais maintenant nous nous intéressons à Java. Comme vous pouvez le constater, les paramètres sont répartis en plusieurs onglets. Ce qui est le plus utile, c'est que le résultat du changement sera affiché dans un exemple sur le côté droit de la fenêtre : Comme vous pouvez le voir sur la capture d'écran, nous pouvons spécifier le paramètre "Appels de méthode chaînés" comme "wrap Always", c'est-à-dire toujours divisé pour les appels de méthode fusionnés. Maintenant, cliquons à nouveau sur le formatage dans le test et voyons que cela fonctionne vraiment ! Mais il arrive parfois qu'il soit nécessaire de formater du code en dehors des règles générales de formatage. Configurons le formatage comme suit : Pour permettre la désactivation du formatage, la prise en charge des marqueurs de désactivation du formatage doit être activée dans la section Style de code : Nous pouvons maintenant modifier le code de notre test pour que sa mise en forme reste sous la forme dans laquelle nous l'écrivons :

@Test
public void testSummOfOddNumbers() {
	List<Integer> data = Arrays.asList(1, 4, 2, 3, 6, 7, 9);
	// @formatter:off
	Integer result = data.stream().filter(number -> number % 2 == 0)
                             .reduce((n1, n2) -> n1 + n2)
                             .get();
	assertThat(result, is(12));
	// @formatter:on
}

Oui, si vous remarquez : lorsque vous appuyez sur Tab, Idea l'interprète comme des espaces pour vous (comportement par défaut). Mais vous pouvez changer cela ici dans Code Style : Comme vous pouvez le constater, il existe une grande variété de paramètres. Vous pouvez en savoir plus sur les paramètres de style de code ici : " Aide sur les idées : Style de code ". Il existe une autre fonctionnalité de formatage importante : le formatage d'importation. Il est exécuté séparément et est appelé "Optimize Imports"et se trouve dans l'élément de menu Code -> Optimize Imports(Ctrl + Alt + O). L'optimisation des importations supprime les importations inutiles et les place également dans le bon ordre en fonction des paramètres de l'onglet Importations des paramètres Style de code pour Java. De plus, si vous souhaitez que le formatage se fasse automatiquement, la bonne nouvelle est que vous pouvez le faire à l'aide du plugin Save Actions .

Distribution des paramètres à une équipe

Génial, nous avons vu ci-dessus que nous pouvions personnaliser le style de formatage à notre convenance. Mais comment ce style peut-il être utilisé en équipe ? Très simple. Il existe plusieurs options. Le plus simple est de sauvegarder le schéma. Ouvrez les paramètres de l'idée via Fichier -> Paramètres (ou appuyez sur Ctrl + Alt + S). Dans la section Code Style, nous pouvons voir l’inscription Scheme. Ceci est notre schéma de formatage. Par défaut, un schéma est spécifié avec le nom Default et à côté se trouve l'annotation IDE : cela signifie que ce paramètre est uniquement pour notre IDE et qu'il n'affecte personne. Pour faire un schéma « personnalisé », cliquez sur le bouton à droite pour en faire un « dupliquer » et donnez-lui un nom, par exemple : JavaRush Après cela, nous pourrons importer ou exporter les paramètres : Une autre option consiste à importer les paramètres d'importation de l'idée : La troisième option est le référentiel de paramètres. Pour plus d'informations sur l'utilisation du référentiel de paramètres, consultez la documentation « Aide IntelliJ Idea : référentiel de paramètres ». Au sujet de la distribution d'un style unique dans l'équipe, je ne peux pas non plus m'empêcher de noter le bon support des styles de l'IDE Eclipse. Pour ce faire, vous devrez installer un plugin séparé : ouvrez les paramètres d'Idea via Fichier -> Paramètres (Ctrl + Alt + S) et accédez à la section Plugins. Pour rechercher de nouveaux plugins, cliquez sur le bouton "Browse Repositories", après quoi nous trouverons le plugin Eclipse Code Formatter dans la fenêtre de recherche. Maintenant, après l'installation, vous devez redémarrer Idea - il s'agit d'une procédure standard. Après cela, au même endroit, dans les paramètres Idea, nous trouverons une nouvelle section : « Eclipse Code Formatter ». Un exemple de fichier de format pour Eclipse peut être trouvé ici . Cela ressemblera à ceci :

Des exigences plus strictes

En plus des outils Idea, vous pouvez également utiliser des plugins de système de build pour renforcer les exigences. Il n'existe aucun moyen de vérifier qu'une personne a utilisé le formatage. S’il y a 5 personnes dans l’équipe, c’est toujours possible. Si l’entreprise compte 100 personnes, ce n’est pas réaliste. Oui, même cinq seront difficiles à suivre. Et pourquoi perdre du temps là-dessus ? Il est beaucoup plus facile d'interdire la collecte d'un projet si certaines règles ne sont pas respectées. En fait, il s'agit d'un tout autre sujet appelé "Inspecter le code". Pour les besoins de cet article, je veux juste montrer comment cela fonctionne. L'un des plugins les plus courants pour Gradle (puisqu'il collecte notre projet, si vous vous en souvenez) est pmd . Pour l'activer, il suffit d'aller dans le script de build de notre projet gradle (le fichier build.gradle à la racine de notre projet) et d'y spécifier pmd à côté du reste des plugins :

plugins {
    // Apply the java plugin to add support for Java
    id 'java'
    // Check source code
    id 'pmd'
    // Apply the application plugin to add support for building an application
    id 'application'
}

Nous pouvons maintenant y définir des paramètres plus détaillés :

pmd {
    ignoreFailures = false
    pmdTest.enabled = true
    ruleSets = [
            'java-basic',
            'java-braces',
            'java-clone',
            'java-codesize',
            'java-comments',
            'java-controversial',
            'java-coupling',
            'java-design',
            'java-empty',
            'java-finalizers',
            'java-imports',
            'java-optimizations',
            'java-strictexception',
            'java-strings',
            'java-typeresolution',
            'java-unnecessary',
            'java-unusedcode'
    ]
}

Même dans notre projet, tout ne va plus bien. Lançons Gradle build et obtenons une erreur. Ce qui est bien, c'est qu'un rapport est généré lors de l'assemblage. Et s'il y a des erreurs, nous recevrons un message du type :

BUILD FAILED in 35s
6 actionable tasks: 6 executed
7 PMD rule violations were found. See the report at: file:///C:/_study/codestyle/build/reports/pmd/main.html

Si nous regardons le rapport, nous verrons quelque chose comme : De plus, dans la colonne Problème, vous trouverez un lien vers une description du problème sur le site Web du plugin pmd. Par exemple, pour l'erreur « headerCommentRequirement Required », le lien va ici : pmd - CommentRequired . Cette erreur nous indique que notre classe n'a pas de JavaDoc. La présence de JavaDoc sur les classes peut être configurée à l'aide de modèles : Et spécifiez le contenu de l'en-tête du fichier : Après cela, nous pouvons transformer le commentaire au-dessus de la classe App en JavaDoc et voir avec un nouveau Build que l'erreur a disparu.

Conclusion

Le style de code est important pour un projet productif. Un beau code écrit selon les règles générales est la garantie que vos collègues le comprendront plus facilement et plus rapidement, et ne diront pas quelques choses affectueuses sur vous. Compte tenu des outils de développement modernes, il n’est pas si difficile de respecter les règles. J'espère que cet examen a montré que c'est effectivement le cas. Bon, comme d'habitude, un peu de matériel sur le sujet :

• Vidéo de JetBrainsTV : « Inspecter le code (IntelliJ IDEA) »
• Revue de « Analyse de code avec les plugins Gradle »
• Cours " Automatiser la qualité du code "

#Viacheslav