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

שפת תכנות דומה מאוד לשפה מדוברת. ההבדל היחיד הוא שמדובר בשפה מיוחדת שמטרתה העיקרית היא להקל על התקשורת עם המחשב על מנת להסביר למחשב מה אנחנו רוצים שהוא יעשה. אבל אתה לא יכול לנהל שיחה אישית עם מחשב. כשהתחלת ללמוד שפת תכנות, הסתכלת על ספרים או משאב חינוכי כלשהו כמו CodeGym. והמשאב הזה הראה לך קוד שהמחשב מבין. אבל גם אתה צריך להבין את זה כשאתה לומד על שפת ג'אווה. כמו בכל שפה, כמה מוסכמות עיצוב אומצו בתכנות. לדוגמה, בחברה מנומסת, כתיבה כך תיחשב לנימוסים רעים. וב-Java, התחלת שם של שיטה באות גדולה היא הפרה בוטה של ​​מוסכמות קידוד. הכללים לקוד Java ניתנים במסמך קונבנציות קוד לשפת התכנות Java . מוסכמות קידוד יכולות גם לווסת פרטים קטנים יותר, כגון הזחה. תארו לעצמכם את הסיוט המוחלט שבקרת גרסאות תהפוך אם ההזחה לא הייתה עקבית, חלק מהאנשים משתמשים בטאבים ואנשים אחרים משתמשים ברווחים. איך זה יהיה עבור מי שצריך לבדוק תיקון בשיטה אחת בלבד, אבל מוצא את כל הקובץ שונה בגלל הבדלים ברווחים ובטאבים? כמובן, כמו בשפה רגילה, המוסכמות עשויות להשתנות בהתאם למקום שבו משתמשים בשפה. לדוגמה, במרחבים העצומים של הרשת, תוכלו למצוא את מדריך הסגנונות של גוגל ג'אווה ואת מדריך הסגנונות של ג'אווה של טוויטר . עבור סקירה זו, אנו זקוקים לנושא מבחן. נשתמש במערכת האוטומציה של בניית 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 testSumOfOddNumbers() {
	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בתפריט IDEA (או הקש Ctrl+Alt+S). הזן "סגנון קוד" בשדה החיפוש בחלון ההגדרות. בקטע "סגנון קוד", אתה יכול לציין הגדרות עבור יותר שפות מאשר רק Java. אבל ג'אווה היא מה שאנחנו מתעניינים בו כרגע. כפי שאתה יכול לראות, ההגדרות מחולקות למספר כרטיסיות. תכונה סופר שימושית היא שדוגמה לפעולה מוצגת בחלק הימני של החלון: צילום המסך מראה שאנחנו יכולים להגדיר את "Chained method calls" ל"wrap always", כלומר תמיד לפצל קריאות שיטה משורשרות לשורות נפרדות. כעת לחץ שוב על כפתור העיצוב בשיעור המבחן ואנחנו רואים שזה באמת עובד! אבל לפעמים אתה צריך לעצב קוד כלשהו מחוץ לכללי העיצוב הסטנדרטיים. הגדר את העיצוב באופן הבא: על מנת למנוע עיצוב, בקטע "סגנון קוד", הפעל את סמני הפורמט: כעת נוכל לשנות את מחלקת הבדיקה שלנו כך שהקוד שלו לא יעבור פורמט:

@Test
public void testSumOfOddNumbers() {
	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 מפרש אותו כרווח (זוהי התנהגות ברירת המחדל). אבל אתה יכול לשנות את זה בקטע " Code Style": כפי שאתה יכול לראות, יש שם הרבה הגדרות. תוכל לקרוא פרטים נוספים על Code styleהגדרות " " כאן: " עזרה של IDEA: סגנון קוד ". יש עוד תכונת עיצוב חשובה: יבוא פורמט. פעולה זו מופעלת בנפרד ונקראת " Optimize Imports". הוא ממוקם תחת Code -> Optimize Imports(Ctrl+Alt+O). אופטימיזציה של יבוא מסיר יבוא מיותר ומסדר את היבוא בסדר הנכון בהתאם להגדרות בלשונית " Imports" של Code Styleהגדרות " " עבור Java. יתרה מכך, אם אתה רוצה שהעיצוב הזה יתרחש אוטומטית, יש חדשות טובות: ניתן להשיג זאת באמצעות תוסף Save Actions .

הפצת הגדרות בפקודה

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

דרישות מחמירות יותר

בנוסף לכלי IDEA, אתה יכול גם להשתמש בתוספים לבניית אוטומציה כדי להחמיר את הדרישות. אין שום סיכוי שתוכל לבדוק ידנית שמישהו השתמש בעיצוב תקין. אולי אתה יכול עם 5 אנשים בצוות. אבל עם 100 אנשים בחברה, זה לא ריאלי. ואפילו חמישה יהיה קשה לעקוב. ולמה לבזבז את זמנך על כל זה? יהיה הרבה יותר קל למנוע את בניית הפרויקט אם הכללים יופרו. למעשה, זהו נושא נפרד לגמרי שנקרא "קוד בדיקה". במאמר זה, אני רק רוצה להראות לך איך זה עובד. אחד התוספים הפופולריים ביותר של Gradle (בגלל שהוא בונה את הפרויקט שלנו, אתה זוכר) הוא pmd . כדי להפעיל את זה, פשוט עבור אל סקריפט הבנייה של פרויקט 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ונקבל שגיאה. הדבר היפה הוא שמופק דוח במהלך הבנייה. ואם יש שגיאות, נקבל הודעה כזו:

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

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

בשורה התחתונה

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

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