מערכים חד מימדיים - שפת C - בדיקת שוני מספרים במערך.

[iib]

למה לא?

[Ghosthunter]

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

[advance512]

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

אלא אם אתה מתכנת system (למשל ב-win32) ובאמת משתמש בשפות ארכאיות באופן קבוע אז אולי כדאי לך לכתוב ככה.

אחרת לא.

יום טוב.

מה אתה מדבר שטויות?

קודם כל, אתה יכול להיות תוכניתן אפליקטיבי לחלוטין גם מעל מערכת ה-Win32 - תכנות ב-MFC או ב-Win32 API, למשל.

נוטציה הונגרית עוזרת במספר מישורים:

1. קריאות קוד. הרבה יותר קל להבין קוד כשמכירים נוטציה הונגרית והיא אחידה בתוך כלל הקוד בצוות - לא צריך להתחיל לחשוב כשרואים קוד חדש. כשקוראים לקוד שאינו שלך רק לפי שמות המשתנים מכירים את הממשק. כשצריך לדבג קוד של מישהו אחר, או כשעושים Code Review, זה בכלל מקל בטירוף.

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

3. מניעת טעויות. תקרא קצת נוטציה הונגרית אפליקטיבית, כאן: http://www.joelonsoftware.com/articles/Wrong.html ותבין על מה אני מדבר.

להסתמך על המרות אוטומטיות (Boxing וכאלה), או על משתני Variant וכו', גם בשפות ה-.NET, גם ב-Java וגם ב-VB הנושנה, גורם לטעויות לא פעם.

לבסוף - C/C++ הן לא שפות ארכאיות, למעשה הם עדיין מאוד פופולאריות - גם היום עם כל שפות הדור 3.5. כשמפתחים פונקציות קטנות, אפשר להסתדר בלי סטנדרטים. גם אז, עדיף עם. כשמפתחים מודולים, עצי ירושה גדולים וכו' - נוטציה הונגרית שווה זהב.

גם ב-C# יש מקום ויתרון גדול לנוטציה הונגרית, למרות שמיקרוסופט יצאו נגדה לחלוטין. אם לא בסטייל המוכר והישן (System), אז בסטייל אפליקטיבי (App).

[iib]

להסתמך על המרות אוטומטיות (Boxing וכאלה), או על משתני Variant וכו', גם בשפות ה-.NET, גם ב-Java וגם ב-VB הנושנה, גורם לטעויות לא פעם. App).

תקשיב ילד,

ההמרות האלה קורות בכל מקרה - ככה הנתונים שלך "מוערכים" על ידי שפות אחרות.

אתה יכול להגביל את עצמך (type casting) לשם שנתת ולהכריח ולכפות את התוכנה לשמות משתנים שלך...

או שאתה יכול להתקדם כמה שנים קדימה ולכתוב קוד שמנצל את הגמישות של התוכנה.

לא לחינם כל השפות המודרניות כוללות את הגמישות הזאת - כנראה שאם היו חושבים שהדרך הנכונה היא להגביל את סוג הנתונים של המשתנה

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

תרצה או לא תרצה נוטציה הונגרית היא לא שיטה הגיונית עבור שפות מתקדמות.

מה שהיה פעם טבעי לעשות מכורך מבנה השפה - היום הוא מעשה כפיה עצמית לצורת חשיבה ישנה ומוגבלת יותר.

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

ואם מה שיש לך להציג זה מאמר של בן אדם שבין השאר מרגיש לא נוח כשלא סוגרים IF עם statement אחד בגרשיים - אז זה ממש עלוב, ומי שחושב ככה - בו נגיד הוא מהשוליים הקיצוניות של הסקאלה של איך לכתוב קוד...

יום טוב.

[advance512]

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

אגב, אני יותר מבוגר ממך ואין לי בכלל ספק שיש לי יותר ניסיון ממך. אנא, דע את מקומך.

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

מסכים עם הדעה שלו לגבי סגירת if, עדיין פסילה של הדעה שלו ע"י תקיפה שלו היא מקרה קלאסי של טיעון

Ad Hominem. שוב, ביזוי של הדיון.

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

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

לג'ואל יש כמה נקודות מאוד טובות, ואם ראית את הדוגמא שלו לתחיליות s ו-us במחרוזות של ASP אין ממש טעם

לדיון.

לגבי Boxing, קרא קצת כאן: http://www.knowdotnet.com/articles/boxing.html

כן, זה מוסיף overhead של יצירת אובייקט מ-value type. עוד זיכרון, עוד זמן וכו'. לולאה פשוטה של חישוב

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

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

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

כתובות

שפות תכנות שונות מאפשרות לך לעשות המון דברים שלאו דווקא תורמים לקוד טוב. דוגמא קלאסית: goto ב-C

ובטח שב-C++. יש קונצנזוס די גדול של הבעיתיות בשימוש ב-goto. (חפש ב-Google את המילים Go To

Statement Considered Harmful למאמר של דייקסטרא, עליו אני מקווה ששמעת, בנושא) לכל דבר יש

שימוש ומקום, כך גם ל-goto ול-type coercion, בעיקר במקרים של קוד quick and dirty. לעומת זאת,

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

בשלבים מוקדמים של הפיתוח ולא בשלב הבדיקות או יותר גרוע, בעת השלב המבצעי. אם זה כל כך טוב, type

coercion, למה לא להשתמש רק ב-objectים? תכתוב קוד כך שתתן תמיד object (מחלקת הבסיס של כל

המחלקות ב-C# וב-Java). אין בעיה, הכל יתקמפל. את הבעיות תגלה בהמשך. אגב, בדיוק כמן הטיעון שלך -

שהעובדה ששפות כוללות את האפשרות להשתמש ב-objects אומרת שמשתנים כללים הם טובים - כך אני יכול

להציג טיעון נגדי, שהעבודה ששפות כוללות מנגנונים מורכבים של type identification ו-type safety אומרת

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

של אוכלוסיית התוכניתנים. תראה לי מישהו שאומר אחרת.

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

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

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

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

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

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

אם יש לך ניסיון בעבודה עם צוותים גדולים ובעבודה על מוצרים רציניים וכבדים אתה מבין על מה אני מדבר.

אם אתה עדיין לא מסכים עימי, אנא ממך - תאר לי מקרה שבו עיצוב ותכנון נכון גוררים שימוש במשתנים גנריים בתוך

מערכת שלמה. אין דברים כאלה.