- Naming Conventions - עקרונות מנחים בקביעת שמות

דף ראשי «

מפת האתר «

אודות האתר «

עזרה «

study.eitan.ac.il «

» נושאי לימוד

יום חמישי 2 במאי 2024

Naming Conventions - עקרונות מנחים בקביעת שמות

דף ראשי

מתחילים לכתוב – עקרונות בקידוד

Naming Conventions - עקרונות מנחים בקביעת שמות

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

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

השמירה על קונבנציות אלה - Naming Conventions באה לידי ביטוי בקוד במספר דרכים:

שמות משמעותיים

שמות משתנה/מודול או פונקציה יהיו משמעותיים ויעידו על תפקידם.

בקרב תוכניתנים מתחילים נפוצה השגיאה לתת שמות כמו x,i למשתנים או f לפונקציה.

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

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

למשל, כשתבוא לקרוא קוד שכתב תוכניתן אחר ותמצא שם:

for (int i = 0; i < c_.size(); ++i)
  {
     C c1= (C)(c_.elementAt (i));
     if (c1.f1(c2))
     {
         c_.removeElement(c1);
         remove (c1);
   }
  }

לעומת זאת, אם תקבל את אותו קטע קוד, אך הפעם עם שמות משמעותיים:

for (int i = 0; i < Cards.size(); ++i)
  {
     Card CurrCard = (Card)(Cards.elementAt (i));
     if (CurrCard.IsPair (CardToMatch))
     {
         Cards.removeElement(CurrCard);
         remove (CurrCard);
   }
  }

הרבה יותר טוב... נכון?

עקביות

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

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

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

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

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

חוסר סרבול

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

AverageNumberOfVacationDaysForMaleEmployees

קצת ארוך, נכון? ואם כל הקוד שלנו יהיה מלא במשתנים כאלה - הוא לעולם לא יהיה קריא. בואו ננסה לקצר:

Anvdme

קצר וקולע? לא בדיוק. אף אחד לא יבין לעולם מה רצינו להגיד במשתנה הזה.

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

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

וזו התוצאה:

MaleEmpAvgNumOfVacDays

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

חד משמעיות

עיקרון פשוט וקל לשמירה אם נעקוב ונקפיד על הסטנדרטים שנקבעו.

ניקח דוגמא:

  // Manager of all employee objects in the system
class CEmpMgr
  {
     CEmp EmpVec; // array of employees
     int ID;      // ID of current employee

     double GetSalaryOfEmp (int ID)
     {
         return EmpVec[ID].GetSalary();
                        // Error! Which ID are we using?
                           // the member defined in the class or
                           // the parameter given to the func??
     }
  };

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

המקרה שבדוגמא יכול להימנע אם נקפיד לתת צורה אחרת של שמות ל-data members, לפרמטרים ולמשתנים מקומיים. למשל, תחילית m לפני שם ה-data_member.

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

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

לדוגמא: בתוכנית שמטפלת בביקור אצל רופא שיניים, המשתנה nPaymentSum

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

לאורך הביקורים בשנה שלמה), אבל עדיף להגדיר nYearlyPaymentSum שהוא חד משמעי.

קצת ת'כלס

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

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