חוסר הבנה, או חוסר קריאה ?

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

אז הבאתי את הדוגמא ההפוכה, בה תרגמתי את הקוד C לקוד פסקל. וכמובן שצפריר ראה רק קוד פסקל, אבל לא התעמק בטקסט אשר דיבר על RFC… אלא בקוד פסקל. כמובן שהנכסתי כמה דברים ש90% מאלו שראו קוד פסקל מימיהם לא ידעו שבכלל אפשר לעשות דברים כאלו, שלא לדבר על התחביר, ובעצם הצגתי חלופה קריאה וטובה יותר לקוד C.

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

אז האם אני מפספס משהו, או שהתחושה ש"אם זה היה קשה לכתוב ולקרוא, אז בטוח שזה יותר טוב" היא המוטו מאחורי הדברים ?

6 מחשבות על “חוסר הבנה, או חוסר קריאה ?

  1. קובי

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

    אזו שפה יותר קריאה ?
    זה עניין של טעם וריח. לי, למשל, יותר קל לראות דוגמה ב c מאשר דוגמה בפסוודו קוד או ב java, python, pascal … .

    אזו שפה יותר זמינה ?
    לפעמים עובדים עם מה שיש, גם אם זה לא נוח. יש הרבה חומרות בהן השפות הזמינות היחידות הן אסמבלי או c, לרוב c תהיה השפה המועדפת.

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

  2. ik_5

    סתם שאלה, איך בעברית, אנגלית וכו' אתה אומר ? "טיפוס מספר שלם יוסי", או "יוסי מטיפוס מספר שלם" ?
    הלוגיקה צריכה להיות מאוד פשוטה… ברגע שאתה צריך להפוך את החשיבה שלך בליישם משהו, אתה גורם לבעיה שיכולה להיות באג. כלומר עצם זה שעכשיו אתה מדבר בצורה אחת וכותב בצורה אחרת גורמת לכך שאיפשהו באמצע יש סיכוי שמשהו לא יוגדר נכון, או בשפה שאתה מדבר או בשפת התכנות שאתה כותב. אז נכון שיש כאן עניין של גישה, אבל כל השפות שאתה הזכרת (למעט פסקל שהגיעה לפני C), מנסות לתקן בדיוק את הבעיות האלו. אפילו ++C ניסתה לתקן, אבל יצרה בעיות חדשות.
    כך שלא רק אני טוען שיש כאן בעיה עם השפה.
    תאורטית (בלבד, כי אנחנו מכירים את המציאות), גם פסקל וגם C, מתחרות על אותו "שוק", כלומר תכנות כללי. כי שניהן מסוגלות לספק את אותן הדברים בדיוק. כאשר הפסקל החדש יותר מסוגל גם להתחרות עם עוד אספקטים שונים, כאשר C נשאר מאחור.

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

    לפני למעלה משנה, התחלתי לחקור את עולם מערכות ההפעלה, בשביל ללמוד יותר לעומק כיצד לכתוב קרנל משל עצמי. מצאתי שהרבה פעמים קוד Assembly היה יותר קריא וברור במה שהוא עושה מאשר קוד C אשר ביצע בדיוק את אותו הדבר ! עכשיו כל מי שאמרתי לו את זה, חשב שאני מגזים, עד אשר הראיתי את הקוד של שני השפות.

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

  3. קובי

    "כל הקטע היה שלא היה צריך להכניס קוד של שפה מסויימת לתקן"

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

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

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

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

  4. צפריר

    הצבעתי בתגובתי שם על בעיה שיכולה להווצר מרמת ההפשטה שלך: מה קורה אם אתה מגדיר טיפוס 3..5 אך מקבל את הערך 0? איך אתה בכלל יכול להתייחס למקרה הזה בקוד שלך? יש שתי דרכים להמנע מזה לחלוטין:
    1. בדיקות יקרות בזמן ריצה – תקורה רצינית מאחורי הקלעים והפוך בדיוק מהדרך של C.
    2. המנעות מטיפוסים שהטווח שלהם אינו מספר שלם של ביטים. אבל אז למה לא להשתמש בהכרזה היעילה והברורה יותר של C?

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

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

  5. ik_5

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

    תזכור שהדבר שאתה עושה אותו הכי הרבה בתכנות (אחרי תכנון) זה לקרוא קוד. אתה יותר קורא קוד מאשר כותב קוד !

להשאיר תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת /  לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת /  לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת /  לשנות )

מתחבר ל-%s

אתר זו עושה שימוש ב-Akismet כדי לסנן תגובות זבל. פרטים נוספים אודות איך המידע מהתגובה שלך יעובד.