IntelliJ IDEA: Codestil und Formatierung

Moderne Tools erleichtern den Entwicklungsprozess. Insbesondere ist es einfacher, den Stil Ihres Codes zu überwachen und zu versuchen, seine „unautorisierte“ Formatierung zu minimieren. In dieser Rezension schlage ich vor, sich mit den Tools vertraut zu machen, die die IntelliJ Idea IDE dem Entwickler zur Verfügung stellt, um den Code angenehm lesbar und leicht verständlich zu machen.

Einführung

Eine Programmiersprache ist der Sprache, die Menschen sprechen, sehr ähnlich. Der einzige Unterschied besteht darin, dass es sich hierbei um eine spezielle Sprache handelt, die zunächst dazu dient, mit einem Computer zu kommunizieren, um ihm zu erklären, was wir von ihm wollen. Aber es kann keine Eins-zu-Eins-Kommunikation mit einem Computer geben. Selbst als Sie mit dem Erlernen einer Programmiersprache begonnen haben, haben Sie sich ein Buch oder eine Bildungsressource wie JavaRush angesehen. Und in dieser Quelle haben Sie Code gesehen, den ein Computer verstehen wird. Sie sollten es aber auch verstehen, wenn Sie sich Kenntnisse in der Java-Sprache aneignen. Wie in jeder Sprache gibt es beim Programmieren einige Regeln für die Codebildung. Beispielsweise gilt das Schreiben mit einem Zaun in einer höflichen Gesellschaft als schlechtes Benehmen, und in Java ist der Aufruf einer Methode mit einem Großbuchstaben ein grober Verstoß gegen den Codestil. Die Regeln zur Formatierung von Java-Code sind im Dokument Java Code Convention formuliert . Darüber hinaus kann der Codestil kleinere Details regeln, etwa die Einrückung. Und wenn Versionskontrolltools verwendet werden, stellen Sie sich den ganzen Albtraum vor, wenn jeder eine Datei entweder als Tabulator oder als Leerzeichen eingerückt speichert. Wie wird es für jemanden sein, der die Bearbeitung mit nur einer Methode überprüfen muss, aber die gesamte Datei aufgrund der Korrektur von Leerzeichen in Tabulatoren oder umgekehrt geändert wird? Natürlich kann der Stil wie bei der gewöhnlichen Sprache je nach Verwendungsort variieren. Im Internet finden Sie beispielsweise den Google Java Style Guide oder den Twitter Java Style Guide . Für diesen Übersichtsartikel benötigen wir eine Testperson. Nutzen wir den Service des Gradle-Projekt-Build-Systems. Dadurch können wir schnell ein neues Projekt mithilfe einer Vorlage erstellen. Gradle hat ein tolles Plugin: Build Init Plugin . Gehen wir in das neue Verzeichnis und führen dort den Befehl aus: gradle init --type java-application Starten Sie anschließend IntelliJ Idea. Wenn Sie ein Fenster mit einem bereits geöffneten Projekt sehen (Sie sehen den Code-Editor, den Projektstrukturbaum), schließen Sie dieses Projekt mit File -< Close Project. Jetzt werden wir im Willkommensfenster "Import Project"unser neues Projekt ausführen und importieren. Setzen Sie beim Importieren das Flag "Use autoimport". Lassen Sie uns herausfinden, ob es möglich ist, das Leben mit Hilfe moderner Entwicklungstools irgendwie zu vereinfachen.

Code in Idea formatieren

Drücken Sie nach dem Importieren des Projekts die Tastenkombination Ctrl+Nund gehen Sie zur Klasse AppTest. Diese Klasse ist die Standardtestklasse. Es sieht aus wie das:

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());
    }
}

Was fällt Ihnen hier sofort ins Auge? Eine Annotation mit einer Methodendeklaration in einer Zeile, die hässlich aussieht, stimme zu. Wie kann man das beheben? IntelliJ Idea verfügt über einen Menübereich "Code"für verschiedene Codemanipulationen. Eine dieser Manipulationen ist "Reformat Code"eine Tastenkombination Ctrl + L. Nach der Anwendung befindet sich die Anmerkung in einer Zeile und die Methode selbst in einer anderen. Es ist sofort erwähnenswert, dass dieser Vorgang für einen ausgewählten Codeabschnitt ausgeführt wird . Und wenn dies nicht der Fall ist, wird der Formatierungsvorgang für alle Inhalte durchgeführt. Fügen wir nun eine neue Testmethode hinzu:

@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));
}

Und zwei Importe:

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

Wie Sie sehen können, wird die Operation für Stream in einer Zeile platziert. Was aber, wenn wir sicherstellen wollen, dass Methoden, deren Aufrufe verkettet sind, immer an einem Punkt in neue Zeilen aufgeteilt werden? Einerseits können wir dies manuell tun. Aber denken Sie daran, dass wir wollen, dass alles für uns funktioniert. Schließlich werden wir es von Zeit zu Zeit vergessen und das Codeformat wird überall anders, und das ist nicht gut. Es stellt sich heraus, dass Sie die Regel bearbeiten müssen, nach der Idea die Formatierung durchführt. Wählen Sie im Menü den Eintrag „Idee“ File -> Settings(oder klicken Sie auf Ctrl + Alt + S). Schreiben Sie in das Suchfeld im Einstellungsfenster „Codestil“. Im Abschnitt Codestil können Einstellungen nicht nur für Java vorgenommen werden. Aber jetzt interessieren wir uns für Java. Wie Sie sehen, sind die Einstellungen in mehrere Registerkarten unterteilt. Am nützlichsten ist, dass das Ergebnis der Änderung in einem Beispiel auf der rechten Seite des Fensters angezeigt wird: Wie Sie im Screenshot sehen können, können wir die Einstellung für „Verkettete Methodenaufrufe“ auf „immer umbrechen“ festlegen, d. h. Bei zusammengeführten Methodenaufrufen immer aufgeteilt. Jetzt drücken wir im Test noch einmal auf Formatieren und schauen, ob es wirklich funktioniert! Aber manchmal kommt es vor, dass Code außerhalb der allgemeinen Formatierungsregeln formatiert werden muss. Lassen Sie uns die Formatierung wie folgt einrichten: Damit die Formatierung deaktiviert werden kann, muss die Unterstützung für die Deaktivierung von Formatierungsmarkierungen im Abschnitt „Codestil“ aktiviert sein: Jetzt können wir den Code unseres Tests so ändern, dass seine Formatierung in der Form bleibt, in der wir ihn schreiben:

@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
}

Ja, wenn Sie Folgendes bemerken: Wenn Sie die Tabulatortaste drücken, interpretiert Idea dies als Leerzeichen für Sie (Standardverhalten). Aber Sie können dies dort im Codestil ändern: Wie Sie sehen, gibt es eine große Vielfalt an Einstellungen. Weitere Informationen zu den Codestileinstellungen finden Sie hier: „ Ideenhilfe: Codestil “. Es gibt eine weitere wichtige Formatierungsfunktion – die Importformatierung. Es wird separat ausgeführt und aufgerufen "Optimize Imports"und befindet sich im Menüpunkt Code -> Optimize Imports(Strg + Alt + O). Durch die Importoptimierung werden unnötige Importe entfernt und in die richtige Reihenfolge gebracht, entsprechend den Einstellungen auf der Registerkarte „Importe“ der Codestil-Einstellungen für Java. Wenn Sie möchten, dass die Formatierung automatisch erfolgt, ist die gute Nachricht, dass Sie dies auch mit dem Save Actions- Plugin tun können .

Verteilen von Einstellungen an ein Team

Großartig, wir haben oben gesehen, dass wir den Formatierungsstil an unsere Bedürfnisse anpassen können. Doch wie lässt sich dieser Stil im Team nutzen? Sehr einfach. Es gibt mehrere Möglichkeiten. Am einfachsten ist es, das Diagramm zu speichern. Öffnen Sie die Idea-Einstellungen über Datei -> Einstellungen (oder drücken Sie Strg + Alt + S). Im Abschnitt „Codestil“ können wir die Aufschrift „Schema“ sehen. Dies ist unser Formatierungsschema. Standardmäßig ist ein Schema mit dem Namen „Default“ angegeben und daneben befindet sich die IDE-Anmerkung: Dies bedeutet, dass diese Einstellung nur für unsere IDE gilt und niemanden betrifft. Um ein „benutzerdefiniertes“ Schema zu erstellen, klicken Sie auf die Schaltfläche rechts, um ein „Duplikat“ zu erstellen und ihm einen Namen zu geben, zum Beispiel: JavaRush Danach können wir die Einstellungen importieren oder exportieren: Eine weitere Möglichkeit besteht darin, Ideeneinstellungen zu importieren: Die dritte Option ist Settings Repository. Weitere Informationen zur Verwendung des Settings Repository finden Sie in der Dokumentation „IntelliJ Idea Help: Settings Repository “. Was das Verteilen eines einzelnen Stils im Team betrifft, kann ich auch nicht umhin, die gute Unterstützung für Stile aus der Eclipse-IDE zu erwähnen. Dazu müssen Sie ein separates Plugin installieren: Öffnen Sie die Idea-Einstellungen über Datei -> Einstellungen (Strg + Alt + S) und gehen Sie zum Abschnitt Plugins. Um nach neuen Plugins zu suchen, klicken Sie auf die Schaltfläche "Browse Repositories", woraufhin wir im Suchfenster das Eclipse Code Formatter-Plugin finden. Nach der Installation müssen Sie Idea nun neu starten – dies ist ein Standardverfahren. Danach finden wir an derselben Stelle in den Idea-Einstellungen einen neuen Abschnitt: „Eclipse Code Formatter“. Ein Beispiel einer Formatdatei für Eclipse finden Sie hier . Es wird ungefähr so ​​aussehen:

Verschärfung der Anforderungen

Zusätzlich zu den Idea-Tools können Sie auch Build-System-Plugins verwenden, um die Anforderungen zu verschärfen. Es gibt keine Möglichkeit zu überprüfen, ob eine Person eine Formatierung verwendet hat. Wenn das Team aus 5 Personen besteht, ist es immer noch möglich. Wenn das Unternehmen 100 Mitarbeiter hat, ist das unrealistisch. Ja, selbst bei fünf wird es schwierig sein, den Überblick zu behalten. Und warum sollte man damit Zeit verschwenden? Es ist viel einfacher, die Sammlung eines Projekts zu verbieten, wenn gegen bestimmte Regeln verstoßen wird. Tatsächlich handelt es sich hierbei um ein ganz separates Thema namens „Inspect Code“. Im Rahmen dieses Artikels möchte ich lediglich zeigen, wie es funktioniert. Eines der häufigsten Plugins für Gradle (da es unser Projekt sammelt, wenn Sie sich erinnern) ist pmd . Um es zu aktivieren, gehen Sie einfach zum Build-Skript unseres Gradle-Projekts (die Datei build.gradle im Stammverzeichnis unseres Projekts) und geben Sie dort neben den restlichen Plugins pmd an:

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'
}

Nun können wir dort detailliertere Einstellungen vornehmen:

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'
    ]
}

Auch in unserem Projekt ist nicht mehr alles gut. Lassen Sie uns Gradle Build ausführen und eine Fehlermeldung erhalten. Das Schöne ist, dass während der Montage ein Bericht erstellt wird. Und wenn es Fehler gibt, erhalten wir eine Nachricht wie:

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

Wenn wir den Bericht aufrufen, sehen wir etwa Folgendes: Darüber hinaus gibt es in der Spalte „Problem“ einen Link zu einer Beschreibung des Problems auf der PMD-Plugin-Website. Für den Fehler „headerCommentRequirement Required“ geht der Link beispielsweise hierher: pmd – CommentRequired . Dieser Fehler weist uns darauf hin, dass unsere Klasse kein JavaDoc hat. Das Vorhandensein von JavaDoc über Klassen kann mithilfe von Vorlagen konfiguriert werden: Und geben Sie den Inhalt für den Dateikopf an: Danach können wir den Kommentar über der App-Klasse in ein JavaDoc umwandeln und mit einem neuen Build sehen, dass der Fehler verschwunden ist.

Endeffekt

Der Codestil ist wichtig für ein produktives Projekt. Schöner, nach allgemeinen Regeln geschriebener Code ist die Garantie dafür, dass Ihre Kollegen ihn einfacher und schneller verstehen und nicht ein paar liebevolle Dinge über Sie sagen. Angesichts moderner Entwicklungstools ist die Einhaltung der Regeln gar nicht so schwierig. Ich hoffe, diese Rezension hat gezeigt, dass dies tatsächlich der Fall ist. Nun, wie immer, ein wenig Material zum Thema:

• Video von JetBrainsTV: „ Inspect Code (IntelliJ IDEA) “
• Rezension zu „ Code-Analyse mit Gradle-Plugins “
• Kurs „ Codequalität automatisieren “

#Wjatscheslaw