אם נשאל את דוד בוב, זה כנראה יהיה עד 100…
קשה באמת להגדיר כמה ארוכה פונקציה צריכה להיות, וכנראה שאי אפשר לנקב במספר ממשי (כל מספר שננקב כנראה יהיה שרירותיׂ), אבל אפשר להתווכח שלפונקציות קצרות יש מספר יתרונות בולטים שקשה להתעלם מהם.
כשאני מתייחס לפונקציות קצרות, הכוונה היא לפירוק הקוד בפונקציה אחת לתתי פונקציות. או כמו שחובבי פילוסופיית היוניקס אוהבים לומר: כל פונקציה צריכה לעשות משהוא אחד, ולעשות אותו טוב. הקוד לא צריך להיות מושפע מאורך הפונקציה. הקוד הוא חלק נפרד, שנכתב בהתאם ליעילות הרלוונטית ועד כמה הוא קריא.
אם ניקח פונקציה ארוכה מאוד ונתחיל לפרק אותה לתתי פונקציות, הדבר הראשון שיבלוט בעין זה שקל יותר להבין מה הפונקציה עושה (אם זה לא ברור לפי השם), ובערך איך היא עושה זאת. זה משמעותית תופס את העין מאשר קטע קוד ארוך שצריך להתחיל לקרוא שורה שורה ולתפוס את התמונה כמו פאזל לא מורכב (לא משנה עד כמה הקוד ‘קריא’).
בנוסף, עטיפת קטעי קוד בפונקציות נותנת לנו עוד שכבת הפשטה. שכבת ההפשטה הזאת מעודדת אותנו להשתמש יותר בפונקציות הקיימות, מצמצמת חזרה על קוד קיים, ומאפשרת לנו יותר גמישות פונקציונאלית בתוך הפונקציות.
מבחינת דיבוג גם יש יתרון- יהיה קל יותר לדבאג פונקציות מפורקות מבלי שנצטרך לדעת איזה חלק בקוד לתפוס כנקודת עצירה.
טסטים גם עשויים לקבל יתרון כשאפשר לבנות יוניט טסטים על פונקציות בודדות במקום על אחת (למרות שעל עקרון כזה יש וויכוח, האם צריך לבדוק את התוצאה של הפונקציה דרך תתי הפונקציות שלה, הוא דרך הפונקציה כמכלול?).
אני אף פעם לא בעד פתרונות שחור או לבן- כי כנראה פתרונות כאלה לא קיימים, לפחות לא בתוכנה. אבל לפונקציות קצרות, המפורקות לתתי פונקציות, כן יש יתרונות מאוד בולטים שקשה להתווכח איתם. לגבי חסרונות? אולי שיש יותר מידי לגו לשחק איתם, והשאלה היא אם זה חסרון מספיק גדול.