IntelliJ IDEA: סגנון קוד ועיצוב

כלים מודרניים מקלים על תהליך הפיתוח. בפרט, קל יותר לפקח על סגנון הקוד שלך, מנסה למזער את העיצוב ה"לא מורשה" שלו. בסקירה זו, אני מציע להכיר את הכלים שה- IntelliJ Idea IDE מספק למפתח כדי להפוך את הקוד לנעים לקריאה וקל להבנה.

מבוא

שפת תכנות דומה מאוד לשפה שאנשים מדברים. ההבדל היחיד הוא שזו שפה מיוחדת שמשמשת בתחילה לתקשורת עם מחשב על מנת להסביר לו מה אנחנו רוצים ממנו. אבל לא יכולה להיות תקשורת אחד על אחד עם מחשב. אפילו כשהתחלת ללמוד שפת תכנות, הסתכלת על ספר או משאב חינוכי כלשהו כמו JavaRush. ובמקור הזה ראית קוד שמחשב יבין. אבל אתה צריך גם להבין את זה כאשר אתה צובר ידע בשפת Java. כמו בכל שפה, לתכנות יש כמה כללים ליצירת קוד. לדוגמה, כתיבה עם גדר בחברה המנומסת נחשבת לנימוסים גרועים, וב-Java קריאה לשיטה באות גדולה היא הפרה בוטה של ​​סגנון הקוד. הכללים לעיצוב קוד Java מנוסחים במסמך Java Code Convention . בנוסף, סגנון הקוד יכול לווסת פרטים קטנים יותר, כגון הזחה. וכאשר משתמשים בכלי בקרת גרסאות, דמיינו את כל הסיוט כשכולם שומרים קובץ שהוזחה ככרטיסייה או שהוזחה כרווח. איך זה יהיה למי שצריך לבדוק את העריכה רק בשיטה אחת, אבל כל הקובץ ישתנה בגלל תיקון רווחים לטאבים או להיפך. באופן טבעי, כמו בשפה רגילה, הסגנון עשוי להשתנות בהתאם למקום השימוש בו. לדוגמה, באינטרנט אתה יכול למצוא את Google Java Style Guide או Twitter Java Style Guide . למאמר סקירה זה, נצטרך נבדק. בואו נשתמש בשירות של מערכת בניית הפרויקט Gradle. זה יאפשר לנו ליצור פרויקט חדש באמצעות תבנית להתחלה מהירה. ל-Gradle יש תוסף מעולה: Build Init Plugin . בוא נלך לספרייה החדשה ונבצע שם את הפקודה: gradle init --type java-application לאחר מכן, הפעל את IntelliJ Idea. אם אתה רואה חלון עם פרויקט שכבר פתוח (תראה את עורך הקוד, עץ מבנה הפרויקט), סגור את הפרויקט הזה באמצעות File -< Close Project. כעת בחלון הפתיחה נבצע "Import Project"וייבא את הפרויקט החדש שלנו. בעת הייבוא, הגדר את הדגל "Use autoimport". בואו להבין האם אפשר איכשהו לפשט את החיים בעזרת כלי פיתוח מודרניים.

עיצוב קוד ב-Idea

לאחר ייבוא ​​הפרוייקט, הקש על צירוף המקשים Ctrl+Nועבור לכיתה AppTest. מחלקה זו היא מחלקת המבחן המוגדרת כברירת מחדל. זה נראה כמו זה:

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

מה מיד מושך את עיניך כאן? ביאור עם הצהרת שיטה על שורה אחת, שנראה מכוער, מסכים. איך לתקן את זה? ל- IntelliJ Idea יש קטע תפריט "Code"למניפולציות שונות של קוד. אחת המניפולציות האלה היא "Reformat Code"שילוב מקשים Ctrl + L. לאחר היישום, ההערה תהיה על שורה אחת, והשיטה עצמה תהיה על שורה אחרת. ראוי לציין מיד כי פעולה זו מבוצעת על קטע נבחר של קוד . ואם אין דבר כזה, פעולת העיצוב תתבצע על כל התוכן. כעת נוסיף שיטת בדיקה חדשה:

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

ושני יבוא:

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

כפי שאתה יכול לראות, הפעולה ב-Stream ממוקמת על קו אחד. אבל מה אם נרצה לוודא ששיטות שהשיחות שלהן משורשרות תמיד מפוצלות בנקודה לקווים חדשים? מצד אחד, אנחנו יכולים לעשות זאת באופן ידני. אבל זכרו שאנחנו רוצים שהכל יעבוד בשבילנו. הרי מדי פעם נשכח, ופורמט הקוד יהפוך להיות שונה בכל מקום, וזה לא טוב. מסתבר שאתה צריך לערוך את הכלל שלפיו Idea מבצע עיצוב. בחר בפריט רעיון בתפריט File -> Settings(או לחץ על Ctrl + Alt + S). בשדה החיפוש בחלון ההגדרות, כתוב "סגנון קוד". בסעיף סגנון קוד אפשר לציין הגדרות לא רק עבור Java. אבל עכשיו אנחנו מתעניינים בג'אווה. כפי שאתה יכול לראות, ההגדרות מחולקות למספר כרטיסיות. מה שהכי שימושי הוא שתוצאת השינוי תוצג בדוגמה בצד ימין של החלון: כפי שניתן לראות בצילום המסך, אנו יכולים לציין את ההגדרה עבור "שיחות שיטת משורשרות" כ-"עטוף תמיד", כלומר. תמיד מפוצל עבור קריאות שיטה ממוזגות. עכשיו בואו נלחץ שוב על עיצוב בבדיקה ונראה שזה באמת עובד! אבל לפעמים קורה שיש צורך לעצב קוד כלשהו מחוץ לכללי העיצוב הכלליים. בואו נגדיר את העיצוב באופן הבא: כדי לאפשר את השבתת העיצוב, יש להפעיל תמיכה בסמני עיצוב בקטע סגנון קוד: כעת נוכל לשנות את הקוד של הבדיקה שלנו כך שהעיצוב שלו יישאר בצורה שבה אנו כותבים אותו:

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

כן, אם תשים לב: כשאתה לוחץ על Tab, Idea מפרש את זה כרווחים עבורך (התנהגות ברירת מחדל). אבל אתה יכול לשנות את זה שם בסגנון קוד: כפי שאתה יכול לראות, יש מגוון עצום של הגדרות. תוכל לקרוא עוד על הגדרות סגנון הקוד כאן: " עזרה לרעיונות: סגנון קוד ". יש עוד תכונת עיצוב חשובה - עיצוב ייבוא. הוא מבוצע בנפרד ונקרא "Optimize Imports"וממוקם בפריט התפריט Code -> Optimize Imports(Ctrl + Alt + O). אופטימיזציית ייבוא ​​מסירה יבוא מיותר וגם מכניסה אותם לסדר הנכון לפי ההגדרות בלשונית יבוא של הגדרות סגנון קוד ל-Java. כמו כן, אם אתה רוצה שהעיצוב יתרחש אוטומטית, החדשות הטובות הן שאתה יכול לעשות זאת באמצעות הפלאגין Save Actions .

הפצת הגדרות לצוות

מצוין, ראינו למעלה שאנחנו יכולים להתאים אישית את סגנון העיצוב כך שיתאים לנו. אבל איך אפשר להשתמש בסגנון הזה בצוות? פשוט מאוד. ישנן מספר אפשרויות. הכי קל הוא לשמור את התרשים. פתח את הגדרות הרעיון דרך קובץ -> הגדרות (או הקש Ctrl + Alt + S). בסעיף סגנון קוד נוכל לראות את תוכנית הכיתוב. זוהי ערכת העיצוב שלנו. כברירת מחדל, מוגדרת סכימה בשם Default ולצידה יש ​​את הערת ה-IDE: זה אומר שההגדרה הזו מיועדת רק ל-IDE שלנו, והיא לא משפיעה על אף אחד. כדי ליצור סכימה "מותאמת אישית", לחץ על הכפתור בצד ימין כדי ליצור "כפול" ולתת לו שם, לדוגמה: JavaRush לאחר מכן נוכל לייבא או לייצא את ההגדרות: אפשרות נוספת היא לייבא הגדרות של ייבוא ​​רעיון: האפשרות השלישית היא מאגר הגדרות. למידע נוסף על שימוש במאגר הגדרות, עיין בתיעוד "עזרה של IntelliJ Idea: מאגר הגדרות ". בנושא הפצת סגנון בודד בצוות, אני גם לא יכול שלא לציין את התמיכה הטובה בסגנונות מה-Eclipse IDE. לשם כך, תצטרכו להתקין תוסף נפרד: פתחו את הגדרות רעיון דרך קובץ -> הגדרות (Ctrl + Alt + S) ועברו לקטע פלאגינים. לחיפוש תוספים חדשים, לחץ על הכפתור "Browse Repositories", לאחר מכן נמצא את התוסף Eclipse Code Formatter בחלון החיפוש. כעת, לאחר ההתקנה, עליך להפעיל מחדש את Idea - זהו הליך סטנדרטי. לאחר מכן, באותו מקום, בהגדרות Idea, נמצא סעיף חדש: "Eclipse Code Formatter" דוגמה לקובץ פורמט עבור Eclipse ניתן למצוא כאן . זה ייראה בערך כך:

דרישות הידוק

בנוסף לכלי Idea, אתה יכול גם להשתמש בתוספים לבניית מערכת כדי להחמיר את הדרישות. אין דרך לבדוק שאדם השתמש בפורמט. אם יש 5 אנשים בצוות, זה עדיין אפשרי. אם לחברה יש 100 אנשים, זה לא ריאלי. כן, אפילו חמישה יהיה קשה לעקוב אחריהם. ולמה לבזבז על זה זמן? הרבה יותר קל לאסור איסוף של פרויקט אם כללים מסוימים מופרים. למעשה, זהו נושא נפרד לגמרי שנקרא "קוד בדיקה". למטרות המאמר הזה, אני רק רוצה להראות איך זה עובד. אחד התוספים הנפוצים ביותר עבור Gradle (מאחר שהוא אוסף את הפרויקט שלנו, אם אתה זוכר) הוא pmd . כדי להפעיל אותו, פשוט עבור אל סקריפט ה-build של פרויקט gradle שלנו (קובץ build.gradle בשורש הפרויקט שלנו) וציין בו pmd לצד שאר התוספים:

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

כעת נוכל להגדיר שם הגדרות מפורטות יותר:

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

גם בפרויקט שלנו הכל כבר לא טוב. בוא נריץ בניית Gradle ונקבל שגיאה. מה שיפה הוא שמופק דוח במהלך ההרכבה. ואם יש שגיאות, נקבל הודעה כמו:

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

אם נלך לדוח, נראה משהו כמו: יתרה מכך, בעמודה בעיה יש קישור לתיאור הבעיה באתר התוסף pmd. לדוגמה, עבור השגיאה "headerCommentRequirement Required" הקישור עובר לכאן: pmd - CommentRequired . שגיאה זו רומזת לנו שלכיתה שלנו אין JavaDoc. ניתן להגדיר את הנוכחות של JavaDoc מעל מחלקות באמצעות תבניות: וציין את התוכן עבור כותרת הקובץ: לאחר מכן, נוכל להפוך את ההערה מעל מחלקת האפליקציה ל-JavaDoc ולראות עם Build חדש שהשגיאה נעלמה.

שורה תחתונה

סגנון קוד חשוב לפרויקט פרודוקטיבי. קוד יפה שנכתב על פי כללים כלליים הוא הערובה שהקולגות שלך יבינו אותו בקלות ובמהירות יותר, ולא יגידו עליך כמה דברים מעוררי חיבה. בהינתן כלי פיתוח מודרניים, עמידה בכללים אינה כל כך קשה. אני מקווה שהסקירה הזו הראתה שזה אכן כך. ובכן, כרגיל, קצת חומר על הנושא:

• סרטון מ-JetBrainsTV: " Inspect Code (IntelliJ IDEA) "
• סקירה של " ניתוח קוד עם תוספים של Gradle "
• קורס " אוטומציה של איכות קוד "

#ויאצ'סלב