פעם, המנטרה הייתה ברורה- קוד עם דוקומנטציה ברורה ומסודרת לכל דבר. היום משום מה, הגישה הזאת התעדנה קצת.
הגישה היום הולכת ככה: הערות זה רע. התוצאה: רואים הרבה מאוד מערכות שלפעמים לא נמצא שורת comment אחת.
האם זה תקין? אולי. האם commenting הפך לילד רע? לא בדיוק.
נתחיל ממקרה קלאסי של נגד הערה: מפתח כתב פונקציה, תיעד כמה שורות יפות ומתובלנות את הביצוע של הקוד, והמשיך לדרכו. כמה ימים אח"כ, תיקן באג, שינה שורה או שתיים, והמשיך לדרכו. אבל רגע, מה עם הדוקומנטציה? אופסי.
ברגע שמתכנת צריך לתעד ולכתוב דוקומנטציה מלאה לכל קוד\פונקציה, הוא ממש מבצע חתונה קתולית בינו לבין הקוד וההערות. יד ביד, כמו זוג אוהבים, הוא ייצטרך לתחזק גם את הקוד וגם את ההערות. זה יוצר עומס, בלבול, שגיאות וכמובן עצבים. וזה לא אמור להיות ככה.
בעיה נוספת שהערות מייצרות לנו היא…זמן. לכתוב הערות לכל דבר לא יתרום אף פעם ליכולת של הקוד, או לביצוע של הקוד. אם זמן הוא מרכיב קריטי בפיתוח, צריך ממש לשקול לדלג על שלב כתיבת ההערות.
הגישה שהתפתחה לה כיום כנגד כתיבת הערות נקראת ROC, כלומר: Really Obvious Code. שהקוד ידבר בפני עצמו, יהיה ברור ומסודר. מי שיירצה להבין איך הקוד עובד, צריך להסתכל על הקוד ולא על הסיפור שמעליו.
אז האם לכתוב הערות הפך לboogyman של המפתחים היום? אז לא, לא בדיוק.
יש מקומות בהם דווקא כן צריך דוקומנטציה ברורה, למשל ב- public API, librarys, שם אתה זקוק שהמשתמש יבין את המימושים השונים ולא יילך לאיבוד. אבל גם שם אפשר ללכת בגישה קצת אחרת מאשר משל של ארנב וצב מעל כל פונקציה. הגישה אומרת כך: כתוב מה הפונקציה צריכה לעשות, ולא מה היא עושה. את הפונקציונאליות של הקוד משאירים לקוד עצמו, ואת הפילוסופיה מאחוריה- להערות.