משטרה, אכיפת חוקים, או המלצות בלבד

לפני כמה ימים נתקלתי במאמר מאת סקוט הנזלמן, המכיל רשימה של המון כלים שסקוט משתמש בהם במהלך עבודתו. זו רשימה ארוכה, מה שקרוי באנגלית exhaustive (מקיפה וממצה). נראה לי שבמקרה הזה אפשר גם לומר שהיא exhausting (מתישה)…. יש בה עשרות כלים שהוא משתמש בהם, ולמרבה ההקלה הוא מחלק אותם לפי קטגוריות. בעיני הרשימה הזו היא אוצר בלום. כל פריט ברשימה שאני מכירה או שיש ברשותי – שימח אותי מאד. כל פריט שאין לי – עורר את סקרנותי.
השניים שעוררו בי רצון להתקין, ושעליהם אני רוצה לדבר בפוסט הזה, היו Microsoft Best Practices Analyzer ו- Code Style Enforcer. על אף שכל אחד מהם יושב בקטגוריה אחרת ברשימה (הראשון יושב תחת ASP.NET Must Haves, והשני תחת Visual Studio.NET Add-Ins), המטרה של שניהם היא לעבור על קוד שנכתב ב-Visual Studio, ולאכוף חוקים. החוקים יכולים לגעת בשלל נושאים – החל מאבטחה וכלה בקונבנציות לכתיבת שמות מאפיינים (naming conventions).
למעשה, כשראיתי את שני הכלים האלה ברשימה של סקוט הנזלמן, נזכרתי בכלי נוסף ששמעתי עליו לא פעם, אשר משרת מטרה דומה- FxCop. החלטתי לנסות את הכלים הללו.
הכלי הראשון שהתקנתי היה FxCop, ומיד לאחר ההתקנה בדקתי קוד מאחד הפרוייקטים שלנו לפי החוקים המוגדרים באופן דיפולטי בכלי הזה. הכלי מאד מצא חן בעיני: זהו כלי חיצוני (מחוץ ל-VS), שמקבל קובץ אסמבלי (יש לו חלון לבחירת הקובץ), והוא עובר על הקוד ומוצא את החריגות מהחוקים. הוא יוצר רשימה דינמית של החריגות, וליד כל חריגה כותב איזה חוק היא מפרה. כך אפשר להחליט שישנם חוקים לא מעניינים אותי, ואני יכולה לנטרל אותם ולהשאר עם החריגות המפרות את החוקים החשובים לי בלבד. מאד מוצא חן בעיני. החלק הבעייתי בשבילי היה בנושא של יצירת חוקים חדשים. זה היה ממש פרוייקט להבין איך אפשר להוסיף חוק חדש. קודם כל, במדריך של MSDN לא היה שום תיעוד של הענין הזה, וגם לא באתר ההורדה של FxCop. לכן ביצעתי חיפוש על הוספת חוק ב-FxCop, והגעתי לדף הזה. מצוין. יש שם פריט שנקרא התאמה אישית ב-FxCop – בדיוק מה שאני מחפשת. הורדתי את הקובץ, וחשכו עיני – פרוייקט ב-VS. תגידו לי, הם השתגעו? כדי לכתוב חוק שייאכוף קוד אני צריכה לכתוב קוד??? זה קצת הזכיר לי קטע מספר של ד”ר סוס: Did I Ever Tell You How Lucky You Are?. בקטע מסופר על עיירה שהיתה בה דבורה עצלנית, ואנשי העיירה רצו לגרום לה לעבוד יותר קשה, ולכן הם הציבו משקיף. הבעיה היתה שגם אחרי הצבת המשקיף, לא היה שיפור בעבודתה של הדבורה, ולכן הם הציבו משקיף על המשקיף. גם המשקיף על המשקיף לא תרם לייעול עבודת הדבורה, אז הם הציבו משקיף על המשקיף על המשקיף…
עברתי לכלי השני Microsoft Best Practices Analyzer. גם הוא כלי חיצוני שמקבל DLL, ומבצע עליו בדיקות. הוא קצת פחות נחמד מהכלי הקודם, לטעמי, בעיקר מפני שיש לו פחות חוקים. גם כאן רציתי לראות איך מוסיפים חוקים חדשים . גם במקרה הזה לא אהבתי את הדרך – כאן אמנם לא הייתי צריכה לבנות פרוייקט שלם, אלא רק לקנפג קובץ XML – אבל הוא מסובך, יש לו כמה חלקים וצריך למלא בכל חלק משהו אחר – בקיצור, לא הצלחתי להבין אותו. בעסה.
אחרון חביב ניסיתי את Code Style Enforcer . הסיבה שהשארתי אותו לסוף היתה שהוא Plugin לתוסף של Visual Studioשצריך להתקין, כלומר צריך להתקין שני דברים – גם את התוסף, וגם את ה-Plugin. יאללה, נלך על זה. הכלי הזה שונה משני הכלים האחרים בשני דברים: הראשון הוא שהוא רץ בתוך VS, והשני הוא שהוא אוכף חוקים בשני תחומים בלבד: קונבנציות לכתיבת שמות, וחוקי נראות (visibility rules) – איזו דרגת נראות יש למשתנים שונים (public, protected וכו’). אחרי שמתקינים אותו, כשנכנסים לפרוייקט ב-VS, אפשר להחליט אם להשתמש באוכף החוק הזה בפרוייקט הנוכחי. אם כן, מתווספים 3 קבצי XML לפרוייקט, שהם מכילים בתוכם את החוקים. מה שממש מצא חן בעיני זה הדרך להתאים את החוקים. לא עוד פרוייקטים ב-VS או קבצי XML מבהילים. כאן יש UI פשוט וחמוד שאפשר להחליט בו איך יש לקרוא למתודות, משתנים, מחלקות ועוד. אחרי שק