קוד בהערה עדיין צריך להתקמפל

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

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

למה אני מתכוון

הערה מיוחדת, מסומנת איכשהו כך שהמהדר יודע להסתכל לתוכה:

/*@
    log_packet(pkt, sizeof(*pkt));
@*/

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

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

מדוע

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

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

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

ההתנגדות

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

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

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

מה זה ידרוש

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

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

העיקרון הכללי

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

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