streamalism.org

1. סקירה כללית

Checkstyle הוא כלי קוד פתוח הבודק קוד מול מערכת חוקים הניתנת להגדרה.

במדריך זה נבחן כיצד לשלב את Checkstyle בפרויקט Java באמצעות Maven ובאמצעות תוספי IDE.

התוספים המוזכרים בסעיפים שלמטה אינם תלויים זה בזה וניתנים לשילוב בנפרד ב- build או IDE שלנו. לדוגמה, אין צורך בתוסף Maven אצלנו pom.xml כדי להריץ את האימות ב- ID Eclipse שלנו.

2. תוסף צ'קסטייל Maven

2.1. תצורת Maven

כדי להוסיף את Checkstyle לפרויקט, עלינו להוסיף את התוסף בסעיף הדיווח של א pom.xml:

   org.apache.maven.plugins maven-checkstyle-plugin 3.0.0 checkstyle.xml 

תוסף זה מגיע עם שני צ'קים מוגדרים מראש, צ'ק בסגנון Sun ובדיקה בסגנון גוגל. בדיקת ברירת המחדל לפרויקט היא sun_checks.xml.

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

את הגרסה האחרונה של התוסף תוכלו למצוא ב- Maven Central.

2.2. יצירת דוחות

כעת, לאחר שתוסף Maven שלנו מוגדר, אנו יכולים ליצור דוח עבור הקוד שלנו על ידי הפעלת ה- אתר mvn פקודה. לאחר סיום הבנייה, הדוח זמין ב יעד / אתר תיקייה תחת השם checkstyle.html.

לדוח Checkstyle ישנם שלושה חלקים עיקריים:

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

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

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

2.3. בניית אינטגרציה

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

אנו עושים זאת על ידי הוספת יעד ביצוע להגדרת התוסף שלנו:

 org.apache.maven.plugins maven-checkstyle-plugin $ {checkstyle-maven-plugin.version} checkstyle.xml 

ה configLocation תכונה מגדירה לאיזה קובץ תצורה להתייחס לאימות.

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

עכשיו, אם ננהל את mvn נקי להתקין פקודה, היא תסרוק את הקבצים להפרות והבנייה תיכשל אם יימצאו הפרות כלשהן.

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

3. תוסף ליקוי חמה

3.1. תצורות

בדיוק כמו בשילוב Maven, Eclipse מאפשר לנו להשתמש בתצורה המותאמת אישית שלנו.

כדי לייבא את התצורה שלנו, עבור אל חלון -> העדפות -> צ'ק סטייל. ב תצורות צ'ק גלובליות לחץ על חָדָשׁ.

זה יפתח דו-שיח שיספק לנו אפשרויות לציין את קובץ התצורה המותאם אישית שלנו.

3.2. דוחות גלישה

כעת, לאחר שהתוסף שלנו מוגדר אנו יכולים להשתמש בו לניתוח הקוד שלנו.

כדי לבדוק את סגנון הקידוד של פרויקט, לחץ באמצעות לחצן העכבר הימני על הפרויקט ב סייר פרויקט ליקוי חמה ובחר CheckStyle -> בדוק קוד עם Checkstyle.

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

לצפייה בדוח הפרה, עבור אל חלון -> הצג תצוגה -> אחר, וחפש אחר Checkstyle. אפשרויות עבור הפרות ו תרשים הפרות צריך להיות מוצג.

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

לחיצה על קטע בתרשים העוגה תביא אותנו לרשימת ההפרות בפועל בקוד.

לחלופין, אנו יכולים לפתוח את בְּעָיָה תצוגה של Eclipse IDE ובדוק את הבעיות המדווחות על ידי התוסף.

הנה תצוגת בעיה לדוגמא של ליקוי חמה:

לחיצה על אחת מהאזהרות תוביל אותנו לקוד בו התרחשה ההפרה.

4. תוסף IntelliJ IDEA

4.1. תְצוּרָה

כמו Eclipse, IntelliJ IDEA גם מאפשר לנו להשתמש בתצורות מותאמות אישית משלנו עם פרויקט.

ב- IDE פתח את ההגדרות וחפש אחר Checkstyle. מוצג חלון שיש לו אפשרות לבחור את ההמחאות שלנו. הקלק על ה + כפתור וחלון ייפתח אשר יאפשר לנו לציין את מיקום הקובץ לשימוש.

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

4.2. דוחות גלישה

עכשיו כשהתוסף שלנו מוגדר, בואו נשתמש בו כדי לבדוק אם קיימות הפרות. כדי לבדוק אם קיימות הפרות של פרויקט מסוים, עבור אל ניתוח -> בדוק קוד.

תוצאות הבדיקות יתנו לנו מבט על ההפרות בסעיף Checkstyle. הנה דוח לדוגמה:

לחיצה על ההפרות תביא אותנו לשורות המדויקות בתיק בהן התרחשו ההפרות.

5. תצורת Checkstyle מותאמת אישית

בקטע ייצור דוחות Maven (סעיף 2.2), השתמשנו בקובץ תצורה מותאם אישית לביצוע בדיקות תקן קידוד משלנו.

יש לנו דרך ליצור קובץ XML תצורה מותאם אישית משלנו אם איננו רוצים להשתמש בבדיקות ארוזות של גוגל או של סאן.

להלן קובץ התצורה המותאם אישית המשמש לבדיקות לעיל:

5.1. הגדרת DOCTYPE

השורה הראשונה של הגדרת ה- DOCTYPE כלומר היא חלק חשוב בקובץ והיא מספרת מאיפה להוריד את ה- DTD כדי שניתן יהיה להבין את התצורות על ידי המערכת.

אם לא נכלול הגדרה זו בקובץ התצורה שלנו לא יהיה קובץ תצורה חוקי.

5.2. מודולים

קובץ תצורה מורכב בעיקר ממודולים. למודול יש תכונה שֵׁם המייצג את מה שהמודול עושה. הערך של שֵׁם תכונה תואמת למחלקה בקוד התוסף שמבוצע בעת הפעלת התוסף.

בואו ללמוד על המודולים השונים הקיימים בתצורה למעלה.

5.3. פרטי המודול

• בּוֹדֵק: המודולים בנויים בעץ שמודול הבדיקה נמצא בשורש. מודול זה מגדיר את המאפיינים שעוברים בתורשה לכל שאר המודולים בתצורה.
• TreeWalker: מודול זה בודק את קבצי המקור הבודדים של Java ומגדיר מאפיינים הרלוונטיים לבדיקת קבצים כאלה.
• AvoidStarImport: מודול זה קובע סטנדרט לאי שימוש בייבוא ​​כוכבים בקוד Java שלנו. יש לו גם מאפיין שמבקש מהתוסף לדווח על חומרת הבעיות כאזהרה. לפיכך, בכל פעם שהפרות כאלה יימצאו בקוד, תסומן אזהרה כנגדן.

לקריאה נוספת על תצורות מותאמות אישית, עברו על קישור זה.

6. ניתוח דוחות עבור פרויקט Spring-Rest

בחלק זה, אנו נשפוך מעט אור על ניתוח שביצעה Checkstyle, תוך שימוש בתצורה המותאמת אישית שנוצרה בסעיף 5 לעיל, על פרויקט מנוחת האביב הזמין ב- GitHub כדוגמא

6.1. יצירת דוחות הפרה

ייבאנו את התצורה ל- Eclipse IDE והנה דוח ההפרה שנוצר עבור הפרויקט:

האזהרות המדווחות כאן אומרות שיש להימנע מיבוא תווים כלליים בקוד. יש לנו שני קבצים שאינם עומדים בתקן זה. כשאנחנו לוחצים על האזהרה זה לוקח אותנו לקובץ Java שיש בו הפרה.

הנה איך HeavyResourceController.java הקובץ מציג את האזהרה שדווחה:

6.2. פתרון הבעיה

שימוש בייבוא ​​כוכבים אינו נוהג טוב באופן כללי מכיוון שהוא יכול ליצור סכסוכים כאשר שתי חבילות או יותר מכילות את אותה מחלקה.

כדוגמה, שקול את הכיתה רשימה, איזה הוא זמין בחבילות java.util ו java.awt שניהם. אם נשתמש גם בייבוא ​​של java.util . * ו java.awt. * המהדר שלנו לא יצליח לקמפל את הקוד כ- רשימה זמין בשתי החבילות.

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

7. מסקנה

במאמר זה סקרנו את היסודות לשילוב Checkstyle בפרויקט Java שלנו.

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

קוד המדגם בו השתמשנו לניתוח סטטי זמין ב- GitHub.