streamalism.org

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

במדריך זה נעבור על עקרונות קידוד נקיים. אנו גם מבינים מדוע קוד נקי חשוב וכיצד להשיג זאת ב- Java. יתר על כן, נראה אם ​​ישנם כלים זמינים שיעזרו לנו.

2. מהו קוד נקי?

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

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

כל טיפש יכול לכתוב קוד שהמחשב יכול להבין. מתכנתים טובים כותבים קוד שבני אדם יכולים להבין.

3. מדוע עלינו לדאוג לקוד נקי?

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

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

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

4. מאפייני קוד נקי

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

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

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

5. נקה קידוד בג'אווה

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

5.1. מבנה הפרויקט

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

בואו נראה כמה מהתיקיות שמייבן מציע ליצור:

• src / main / java: עבור קבצי מקור
• src / main / resources: עבור קבצי משאבים, כמו מאפיינים
• src / test / java: עבור קבצי מקור הבדיקה
• src / test / resources: עבור קבצי משאבי בדיקה, כמו מאפיינים

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

5.2. ועידת שמות

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

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

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

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

לקוח בכיתה ציבורית {}

• משתנים: משתנים ב- Java לוכדים את מצב האובייקט שנוצר ממחלקה. שם המשתנה צריך לתאר את כוונת המשתנה באופן ברור:

מעמד ציבורי לקוח {private String customerName; }

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

מעמד ציבורי לקוח {private String customerName; מחרוזת ציבורית getCustomerName () {להחזיר this.customerName; }}

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

5.3. מבנה קובץ המקור

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

בואו נראה איך צריך להיראות סדר רגיל של אלמנטים בקובץ מקור:

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

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

בואו נראה קובץ מקור מעוצב היטב:

# /src/main/java/com/baeldung/application/entity/Customer.java חבילה com.baeldung.application.entity; ייבא java.util.Date; מעמד ציבורי לקוח {private String customerName; תאריך הצטרפות תאריך פרטי; לקוח ציבורי (מחרוזת שם לקוח) {this.customerName = customerName; this.joiningDate = תאריך חדש (); } מחרוזת ציבורית getCustomerName () {להחזיר this.customerName; } תאריך ציבורי getJoiningDate () {להחזיר this.joiningDate; }}

5.4. מרחבים לבנים

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

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

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

הרשימה כאן אינה ממצה, אך אמורה לתת לנו קשר לפנות אליה.

5.5. הֲזָחָה

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

בואו נראה כמה מקריטריוני הכניסה החשובים:

• שיטה מומלצת אופיינית היא להשתמש בארבעה רווחים, יחידת כניסה. שים לב שחלק מההנחיות מציעות כרטיסייה במקום רווחים. אמנם אין כאן שיטות עבודה מומלצות מוחלטות, אך המפתח נשאר עקביות!
• בדרך כלל, צריכה להיות מכסה על אורך הקו, אך ניתן להגדיר זאת גבוה מ- 80 המסורתיים, בגלל שימוש במסכים גדולים יותר המפתחים משתמשים כיום.
• לבסוף, מכיוון שביטויים רבים לא יתאימו לשורה אחת, עלינו לשבור אותם בעקביות:
  • קריאות בשיטת Break לאחר פסיק
  • לשבור ביטויים לפני מפעיל
  • קווים עטופים בכניסה לקריאה טובה יותר (אנחנו כאן בבלדונג מעדיפים שני רווחים)

בואו נראה דוגמה:

רשימת customerIds = customer.stream () .map (customer -> customer.getCustomerId ()) .collect (Collectors.toCollection (ArrayList :: new));

5.6. פרמטרים של שיטה

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

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

בואו נראה דוגמה לכך:

set בוליאני ציבוריCustomerAddress (שם מחרוזת, שם משפחה מחרוזת, רחוב כתובת מחרוזת, עיר מחרוזת, zipCode מחרוזת, מצב מחרוזת, מדינה מחרוזת, מספר מחרוזת) {} // ניתן לשחזר זאת כמפורט להלן כדי להגדיל את הקריאה להגדיר את הקריאה הבוליאנית.

5.7. קידוד קשה

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

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

בואו נראה דוגמה:

חנות פרטית פרטיתClosureDay = 7; // ניתן לשחזר זאת לשימוש בקבוע קבוע מ- Java private int storeClosureDay = DayOfWeek.SUNDAY.getValue ()

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

5.8. הערות קוד

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

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

• תיעוד / הערות JavaDoc
  • הקהל כאן הוא המשתמשים בבסיס הקוד
  • הפרטים כאן הם בדרך כלל ללא יישום, ומתמקדים יותר במפרט
  • בדרך כלל שימושי ללא תלות בבסיס הקוד
• הערות יישום / חסום
  • הקהל כאן הוא המפתחים שעובדים על בסיס הקוד
  • הפרטים כאן הם ספציפיים ליישום
  • בדרך כלל שימושי יחד עם בסיס הקוד

אז איך עלינו להשתמש בהם בצורה אופטימלית כך שהם יהיו שימושיים וקונטקסטואליים?

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

בואו נראה דוגמה להערת תיעוד משמעותית:

/ ** * שיטה זו נועדה להוסיף כתובת חדשה עבור הלקוח. * עם זאת שימו לב שהוא מאפשר כתובת אחת בלבד לכל מיקוד *. לפיכך, זה יעקוף כל כתובת קודמת עם אותה מיקוד *. * * @param כתובת לכתובת שיש להוסיף ללקוח קיים * / / * * שיטה זו עושה שימוש ביישום המותאם אישית של שווה שווה * כדי למנוע כפילות של כתובת עם אותו מיקוד. * / public addCustomerAddress (כתובת כתובת) {}

5.9. רישום

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

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

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

בואו נראה דוגמה של רישום תיאורי ברמה הנכונה:

logger.info (String.format ("לקוח חדש נוצר עם זיהוי לקוח:% s", id));

6. האם זה הכל?

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

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

6.1. מוצק

SOLID הוא ראשי תיבות מזכירים השואבים מחמשת העקרונות שהיא מגדירה לכתיבת תוכנות מובנות ומתוחזקות:

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

6.2. יבש ונשיקה

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

KISS מייצג את "Keep It Simple, Stupid". עיקרון זה קובע זאת עלינו לנסות לשמור על הקוד הכי פשוט שאפשר. זה מקל על ההבנה והתחזוקה לאורך זמן. בעקבות כמה מהעקרונות שהוזכרו קודם לכן, אם נשמור על הכיתות והשיטות שלנו ממוקדות וקטנות, זה יוביל לקוד פשוט יותר.

6.3. TDD

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

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

7. כלים לעזרה

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

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

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

• מעצבי קוד: מרבית עורכי קוד Java הפופולריים, כולל Eclipse ו- IntelliJ, מאפשרים עיצוב קוד אוטומטי. אנו יכולים להשתמש בכללי העיצוב המוגדרים כברירת מחדל, להתאים אותם אישית או להחליף אותם בכללי עיצוב מותאמים אישית. זה דואג להרבה מוסכמות קוד מבניות.
• כלי ניתוח סטטי: ישנם כמה כלים לניתוח קוד סטטי עבור Java, כולל SonarQube, Checkstyle, PMD ו- SpotBugs. יש להם סט עשיר של כללים אשר ניתן להשתמש בהם כפי שהוא או להתאים אישית לפרויקט מסוים. הם נהדרים בזיהוי ריחות רבים של קוד כמו הפרות של מוסכמות שמות ודליפת משאבים.

8. מסקנה

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

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

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