קודם כל אני חושב שיש 2 סיבות עיקריות לכתוב הערות:1.אם אנחנו כותבים API של פונקציות שאנחנו הולכים להחצין בסופו של דבר הדרך הכי נוחה תהיה להשתמש בהערכות (יש פשוט המון מערכות שיודעות לייצר דוקומנטציה לפי התיעוד של הפונקציה)
2.אני בעד חלוקה של הקוד לכמה שיותר תפקידים ממש כמו הצגה, כל פונקציה יש לה את התפקיד שלה, ככה אם אנחנו כותבים אלגוריתם מורכב אז להמנע מג'אנקים של קוד בפונקציה אחת, זה לא קריא זה לא מועיל לאף אחד, ואתם תשכחו מהר מאוד מה כל חלק עושה, אז חלוקה לפונקציות זה כבר רעיון טוב.
עכשיו בוא נניח שיש לנו פונקציה שמבצעת פעולה מסויימת ומסיימת לרוץ, אז הכל טוב ויפה, אם כתבנו את הקוד בצורה אלגנטית, עם שמות ראויים לכל פונקציה וכל משתנה, ועבדנו לפי קונבנציה נכונה, אנחנו לא באמת אמורים לתעד משהו זה אמור להיות ברור כשמש. אני מדבר על פונקציות שבעיקר מבצעות פעולות סטטיות בלי תלות בתהליכים מורכבים.
אבל יש גם המון מקרים שהקוד שאנחנו מריצים יש לו תלות בתהליכים אחרים, נתקלתי המון פעמים בקודים מטורפים שהייתי צריך לפענח אותם במשך שעות, אבל אם מישהו היה כותב איזה comment שx לא יכול לעבוד בלי y אז זה היה חוסך לי שעות של עבודה.
אני נגד תיאור של אלגוריתמים, כי בדרך כלל אף אחד לא ממיצא את הגלגל מחדש כי אין באמת צורך, אם מדובר בsorting algorithms או כל פעולה מורכבת אחרת, היא תמיד תהיה מבוססת על רעיון קיים (אז אולי כן שווה להוסיף שורה אחת שאומרת This code is base on x algorithm: http://wiki/algorithm
אבל ברגע שאני רואה הערה מהסוג הזה זה מטריף אותי:
//now we checking if x is equal to y if (x === y)
|
לתאר חלק ממבני הבקרה של השפה זה מגוחך בעיני.
בכל אופן הדגש הוא בעיקר צריך להיות על קוד קריא, מחולק לstages כמה שאפשר, שימוש מקסימלי במושג פונקציה, אם יש לכם קטע קוד שמבצע משהו ספציפי אל תשאירו אותו בתוך האלגוריתם, לפצל כמה שיותר, ככה גם תוכלו מתי שהוא לעשות unit testing למערכות שלכם בקלות.
גירסת הדפסה
סגן המנהל
מפקח
Winner
צל"ש
מומחה
