انتقل إلى المحتوى

التدوين الهنغاري

هذه المقالة يتيمة. ساعد بإضافة وصلة إليها في مقالة متعلقة بها
غير مفحوصة
يرجى مراجعة هذه المقالة وإزالة وسم المقالات غير المراجعة، ووسمها بوسوم الصيانة المناسبة.
من ويكيبيديا، الموسوعة الحرة

الترميز الهنغاري هو اصطلاح لتسمية المعرفات في برمجة الحاسوب حيث يشير اسم المتغير أو الدالة إلى الغرض المقصود منها أو نوعها، أو في بعض اللهجات، إلى نوع البيانات الخاص بها. يستخدم الترميز الهنغاري الأصلي فقط الغرض أو النوع في اصطلاح التسمية الخاصة به ويطلق عليه أحيانًا اسم Apps Hungarian لأنه أصبح شائعًا في قسم Microsoft Apps في تطوير تطبيقات Microsoft Office . عندما تبنى قسم Microsoft Windows اتفاقية التسمية، فقد استندوا إليها على نوع البيانات الفعلي، وانتشرت هذه الاتفاقية على نطاق واسع من خلال واجهة برمجة تطبيقات Windows ؛ وهذا ما يسمى أحيانًا بتدوين الأنظمة المجرية .

 

Simonyi: ...BCPL [had] a single type which was a 16-bit word... not that it matters.

Booch: Unless you continue the Hungarian notation.

Simonyi: Absolutely... we went over to the typed languages too later ... But ... we would look at one name and I would tell you exactly a lot about that...[1]

تم تصميم الترميز الهنغاري ليكون مستقلاً عن اللغة، ووجد استخدامه الرئيسي لأول مرة مع لغة البرمجة BCPL . ونظرًا لأن لغة BCPL لا تحتوي على أنواع بيانات باستثناءكلمة الآلة، فلا يوجد في اللغة ما يساعد المبرمج على تذكر أنواع المتغيرات. تهدف التدوينة المجرية إلى معالجة هذه المشكلة من خلال تزويد المبرمج بمعرفة واضحة حول نوع بيانات كل متغير.

في الترميز الهنغاري، يبدأ اسم المتغير بمجموعة من الأحرف الصغيرة التي تكون بمثابة اختصارات لنوع أو غرض هذا المتغير، تليها أي تسمية يختارها المبرمج؛ ويُشار إلى هذا الجزء الأخير أحيانًا بالاسم المُعطى. يمكن كتابة الحرف الأول من الاسم المعطى بأحرف كبيرة لفصله عن مؤشرات النوع (انظر أيضًا CamelCase ). وإلا فإن حالة هذه الشخصية تشير إلى النطاق.

تاريخ

[عدل]

تم اختراع الترميز الهنغاري من قبل تشارلز سيموني ، وهو مبرمج عمل في مركز بارك التابع لشركة زيروكس تقريبًا بين عامي 1972و 1981، والذي أصبح لاحقًا كبير المهندسين المعماريين في شركة مايكروسوفت . يشير اسم هذا الترميز إلى أصل سيموني الوطني، وأيضًا، وفقًا لأندي هيرتزفيلد ، لأنه جعل البرامج "تبدو كما لو كانت مكتوبة بلغة أجنبية غامضة". [2] أسماء الشعب المجري "مقلوبة" مقارنة بمعظم الأسماء الأوروبية الأخرى؛ حيث يسبق اسم العائلة الاسم المعطى. فعلى سبيل المثال، فإن الاسم المُعرب "Charles Simonyi"كان بالأصل باللغة المجرية كان في الأصل "Simonyi Károly". وبنفس الطريقة، يسبق اسم النوع "الاسم المعطى" في التدوين المجري. كان نمط تسمية "النوع الأخير" المماثل لـ Smalltalk (على سبيل المثال aPoint وlastPoint) شائعًا في Xerox PARC أثناء فترة عمل Simonyi هناك.[بحاجة لمصدر][ بحاجة لمصدر ]

أشار بحث سيموني حول الترميز إلى البادئات المستخدمة للإشارة إلى "نوع" المعلومات التي يتم تخزينها. [3] [4] كان اقتراحه يركز إلى حد كبير على تزيين أسماء المعرفات بناءً على المعلومات الدلالية لما تخزنه (بمعنى آخر، غرض المتغير). أصبح يُطلع على ترميز سيموني اسم Apps Hungarian، حيث تم استخدام هذا الاصطلاح في قسم التطبيقات في Microsoft. تم تطوير الأنظمة المجرية لاحقًا في فريق تطوير Microsoft Windows . لا تختلف تطبيقات اللغة المجرية تمامًا عن ما أصبح يُعرف باسم أنظمة اللغة المجرية، حيث تحتوي بعض البادئات التي اقترحها سيموني على معلومات دلالية قليلة أو معدومة (انظر أدناه للحصول على أمثلة). [4]

الأنظمة المجرية مقابل التطبيقات المجرية

[عدل]

يكمن الاختلاف بين ترميز النظام وترميز التطبيقات في الغرض من البادئات.

في الترميز الهنغاري للنظام، ترمز البادئة إلى نوع البيانات الفعلي للمتغير. على سبيل المثال:

  • lAccountNum :المتغير هو عدد صحيح طويل ( "l" );
  • arru8NumberList : المتغير عبارة عن مجموعة من الأعداد الصحيحة غير الموقعة المكونة من 8 بتات ( "arru8" );
  • bReadLine(bPort,&arru8NumberList) : دالة تحتوي على رمز إرجاع قيمة البايت.
  • strName :يمثل المتغير سلسلة ( "str" ) تحتوي على الاسم، لكنه لا يحدد كيفية تنفيذ هذه السلسلة.

يسعى الترميز الهنغاري للتطبيقات إلى ترميز نوع البيانات المنطقي بدلاً من نوع البيانات الفعلي؛ وبهذه الطريقة، يعطي تلميحًا حول غرض المتغير أو ما يمثله.

  • rwPosition : المتغير يمثل صفًا ( "rw" );
  • usName : يمثل المتغير سلسلة غير آمنة ( "us" )، والتي تحتاج إلى "تطهير" قبل استخدامها (على سبيل المثال، راجع حقن التعليمات البرمجية وبرمجة النصوص عبر المواقع للحصول على أمثلة للهجمات التي يمكن أن تحدث بسبب استخدام إدخال المستخدم الخام)
  • szName : المتغير عبارة عن سلسلة نصية منتهية بـ z ( "sz" ); كانت هذه إحدى البادئات الأصلية التي اقترحها سيموني.

معظم البادئات التي اقترحها سيموني، ولكن ليس جميعها، هي دلالية بطبيعتها. وبالنسبة للعين الحديثة، يبدو أن بعض البادئات تمثل أنواع بيانات فعلية، مثل sz للسلاسل النصية. ومع ذلك، كانت هذه البادئات لا تزال ذات دلالة دلالية، حيث كان سيموني يقصد استخدام التدوين المجري للغات التي لا تستطيع أنظمة الكتابة الخاصة بها التمييز بين بعض أنواع البيانات التي تعتبرها اللغات الحديثة أمراً مسلماً به.

وفيما يلي أمثلة من الورقة الأصلية: [5]

  • p X هو مؤشر إلى نوع آخر من X ؛ ويحتوي على معلومات دلالية قليلة جدًا.
  • d هي بادئة تعني الفرق بين قيمتين؛ على سبيل المثال، قد يمثل dY مسافة على طول المحور Y في الرسم البياني، بينما قد يكون المتغير المسمى y موضعًا مطلقًا. وهذا أمر دلالي تماما في طبيعته.
  • sz عبارة عن سلسلة منتهية بصفر أو لا شيء. في لغة C، يحتوي هذا على بعض المعلومات الدلالية لأنه ليس من الواضح ما إذا كان المتغير من نوع char* هو مؤشر إلى حرف واحد أو مجموعة من الأحرف أو سلسلة منتهية بصفر.
  • يشير w إلى متغير عبارة عن كلمة. لا يحتوي هذا على أي معلومات دلالية على الإطلاق، وربما يُعتبر أنظمة مجرية.
  • يشير الحرف b إلى بايت، والذي على عكس الحرف w قد يحتوي على معلومات دلالية، لأنه في لغة C فإن نوع البيانات الوحيد بحجم البايت هو char ، لذلك يتم استخدامها أحيانًا لحمل القيم الرقمية. قد تساعد هذه البادئة في توضيح الغموض حول ما إذا كان المتغير يحمل قيمة يجب التعامل معها كحرف أو رقم.

بينما يستخدم الترميز دائمًا أحرفًا صغيرة في البداية كرموز تذكيرية، فإنه لا يفرض الرموز التذكيرية نفسها. هناك العديد من الاصطلاحات الشائعة الاستخدام (انظر الأمثلة أدناه)، ولكن يمكن استخدام أي مجموعة من الأحرف، طالما كانت متسقة ضمن مجموعة معينة من التعليمات البرمجية.

من الممكن أن يحتوي الكود الذي يستخدم ترميز Apps Hungarian للتطبيقات أحيانًا على الترميز الهنغاري للنظام عند وصف المتغيرات التي تُعرّف فقط من حيث نوعها.

العلاقة مع الرموز

[عدل]

في بعض لغات البرمجة، توجد الآن اصطلاحات مشابهة تُسمى السيغيلات (sigils) مدمجة في اللغة ومُلزمة من قبل المترجم . على سبيل المثال، في بعض أشكال BASIC ، name$ يدل سلسلة و count% يسمي عددًا صحيحًا . الفرق الرئيسي بين التدوين المجري والرموز هو أن الرموز تعلن عن نوع المتغير في اللغة، في حين أن التدوين المجري هو مجرد مخطط تسمية ليس له أي تأثير على تفسير الآلة لنص البرنامج.

أمثلة

[عدل]

تتبع الرموز التذكيرية للمؤشرات والمصفوفات ،التي ليست أنواع بيانات فعلية، عادةً بنوع عنصر البيانات نفسه:

  • pszOwner : مؤشر إلى سلسلة منتهية بصفر
  • rgfpBalances : مجموعة من القيم العشرية
  • aulColors : مجموعة من العناصر الطويلة غير الموقعة (الأنظمة)

بينما يمكن تطبيق الترميز الهنغاري على أي لغة برمجة وبيئة، فقد اعتمدته مايكروسوفت على نطاق واسع للاستخدام مع لغة C، وبشكل خاص لنظام Microsoft Windows ، ولا يزال استخدامه محصورًا إلى حد كبير في هذا المجال. وعلى وجه الخصوص، تم الترويج لاستخدام الترميز الهنغاري بشكل واسع من خلال كتاب "برمجة Windows" لـ Charles Petzold ، الكتاب الأصلي (وللعديد من القراء، الكتاب النهائي) في برمجة تطبيقات Windows . وبالتالي، فإن العديد من التركيبات الشائعة للترميز الهنغاري خاصة بنظام Windows:

  • بالنسبة للمبرمجين الذين تعلموا برمجة Windows بلغة C، ربما تكون الأمثلة الأكثر تذكرًا هي wParam (معلمة حجم الكلمة) و lParam (معلمة العدد الصحيح الطويل) لوظيفة WindowProc ().
  • hwndFoo : مقبض للنافذة
  • lpszBar : مؤشر طويل إلى سلسلة منتهية بصفر

يُوسَّع الترميز أحيانًا في C++ ليشمل نطاق المتغير، ويمكن فصله اختياريًا بواسطة الشرطة السفلية. [6] [7] غالبًا ما يتم استخدام هذا الامتداد أيضًا بدون مواصفات النوع المجرية:

  • g_nWheels : عضو في مساحة اسم عالمية، عدد صحيح
  • m_nWheels : عضو في هيكل/فئة، عدد صحيح
  • m_wheels ، _wheels : عضو في هيكل/فئة
  • s_wheels : عضو ثابت في فئة
  • c_wheels : عضو ثابت في الدالة

المزايا

[عدل]

(بعض هذه القواعد تنطبق على الأنظمة المجرية فقط.)

يزعم المؤيدون أن فوائد التدوين المجري تشمل: [5]

  • يمكن رؤية نوع الرمز من اسمه. يُعد هذا مفيدًا عند النظر إلى الكود خارج بيئة التطوير المتكاملة — مثل مراجعة الكود أو النسخة المطبوعة — أو عندما يكون إعلان الرمز في ملف آخر من نقطة الاستخدام، مثل الوظيفة.
  • في لغة تستخدم الكتابة الديناميكية أو غير المكتوبة، تتوقف الزخارف التي تشير إلى الأنواع عن كونها مكررة. في مثل هذه اللغات، لا يتم عادةً إعلان المتغيرات على أنها تحمل نوعًا معينًا من البيانات، وبالتالي فإن الدليل الوحيد على العمليات التي يمكن إجراؤها عليها هي التلميحات التي يقدمها المبرمج، مثل مخطط تسمية المتغيرات والتوثيق والتعليقات. كما ذكر أعلاه، تم توسيع التدوين المجري في مثل هذه اللغة ( BCPL ).
  • قد يؤدي تنسيق أسماء المتغيرات إلى تبسيط بعض جوانب إعادة هيكلة الكود (بينما يجعل الجوانب الأخرى أكثر عرضة للخطأ).
  • يمكن استخدام متغيرات متعددة ذات دلالات مماثلة في كتلة من التعليمات البرمجية: dwWidth، iWidth، fWidth، dWidth.
  • يمكن أن يكون من السهل تذكر أسماء المتغيرات من خلال معرفة أنواعها فقط.
  • ويؤدي ذلك إلى أسماء متغيرات أكثر اتساقًا.
  • من الممكن اكتشاف عمليات تحويل النوع غير المناسبة والعمليات التي تستخدم أنواعًا غير متوافقة بسهولة أثناء قراءة الكود.
  • في البرامج المعقدة التي تحتوي على العديد من الكائنات العالمية (نماذج VB/Delphi)، فإن وجود تدوين بادئة أساسي يمكن أن يسهل مهمة العثور على المكون داخل المحرر. على سبيل المثال، قد يؤدي البحث عن السلسلة btn إلى العثور على كافة كائنات الزر.
  • يساعد تطبيق التدوين المجري بطريقة أضيق، مثل تطبيقه على المتغيرات الأعضاء فقط، على تجنب تضارب التسمية .
  • يصبح الكود المطبوع أكثر وضوحًا للقارئ في حالة أنواع البيانات، وتحويلات النوع، والتعيينات، والاقتطاعات، وما إلى ذلك.

العيوب

[عدل]

معظم الحجج المعارضة للترميز الهنغاري تكون ضد الترميز الهنغاري للنظام، وليس الترميز الهنغاري للتطبيقات[بحاجة لمصدر] . بعض المشاكل المحتملة هي:

  • يصبح التدوين المجري زائداً عن الحاجة عندما يقوم المترجم بإجراء فحص النوع. تضمن المجمِّعات الخاصة بلغات البرمجة التي توفر فحصًا صارمًا للنوع، مثل Pascal ، أن يكون استخدام المتغير متوافقًا مع نوعه تلقائيًا؛ فالفحوصات بالعين غير ضرورية وعرضة للخطأ البشري.
  • تعرض معظم بيئات التطوير المتكاملة الحديثة أنواعًا متغيرة عند الطلب، وتقوم تلقائيًا بوضع علامة على العمليات التي تستخدم أنواعًا غير متوافقة، مما يجعل هذه الطريقة قديمة إلى حد كبير.
  • يصبح التدوين المجري مربكًا عندما يتم استخدامه لتمثيل العديد من الخصائص، كما في a_crszkvc30LastNameCol : وسيطة ، أي ثابتة ، وهي مرجع يحمل محتويات عمود قاعدة البيانات LastName من نوع varchar (30) وهو جزء من المفتاح الأساسي للجدول.
  • قد يؤدي ذلك إلى عدم التناسق عند تعديل الكود أو نقله. إذا تم تغيير نوع المتغير، فإن الزخرفة الموجودة على اسم المتغير ستكون غير متوافقة مع النوع الجديد، أو يجب تغيير اسم المتغير. ومن الأمثلة المعروفة بشكل خاص نوع WPARAM القياسي، ومعلمة wParam الرسمية المصاحبة في العديد من إعلانات وظائف نظام Windows. يشير الحرف "w" إلى "الكلمة"، حيث أن "الكلمة" هو حجم الكلمة الأصلي للهندسة المعمارية للأجهزة الخاصة بالمنصة. كان في الأصل نوعًا مكونًا من 16 بتًا في بنيات الكلمات المكونة من 16 بتًا، ولكن تم تغييره إلى نوع مكون من 32 بتًا في بنيات الكلمات المكونة من 32 بتًا، أو نوع مكون من 64 بتًا في بنيات الكلمات المكونة من 64 بتًا في الإصدارات اللاحقة من نظام التشغيل مع الاحتفاظ باسمه الأصلي (نوعه الأساسي الحقيقي هو UINT_PTR، أي عدد صحيح غير موقّع كبير بما يكفي لحمل مؤشر). تعتمد المعاوقة الدلالية، وبالتالي ارتباك المبرمج وعدم الاتساق من منصة إلى أخرى، على افتراض أن "w" تعني كلمة مكونة من بايتين و16 بت في تلك البيئات المختلفة.
  • في أغلب الأحيان، معرفة استخدام المتغير يعني معرفة نوعه. علاوة على ذلك، إذا لم يكن استخدام المتغير معروفًا، فلا يمكن استنتاجه من نوعه.
  • يقلل التدوين المجري من فوائد استخدام محرري التعليمات البرمجية التي تدعم الإكمال على أسماء المتغيرات، حيث يتعين على المبرمج إدخال معرف النوع أولاً، وهو ما يكون أكثر عرضة للتصادم مع متغيرات أخرى مقارنة باستخدام مخططات التسمية الأخرى.
  • إنه يجعل الكود أقل قابلية للقراءة، عن طريق إخفاء غرض المتغير باستخدام بادئات النوع والنطاق. [8]
  • قد لا تتمكن معلومات النوع الإضافية من استبدال الأسماء الوصفية بشكل كافٍ. على سبيل المثال، لا يخبر sDatabase القارئ بما هو عليه. قد يكون اسم قاعدة البيانات اسمًا أكثر وصفًا.
  • عندما تكون الأسماء وصفية بدرجة كافية، فقد تكون معلومات النوع الإضافية زائدة عن الحاجة. على سبيل المثال، من المرجح أن يكون الاسم الأول عبارة عن سلسلة. لذا فإن تسميته sFirstName يضيف فقط فوضى إلى الكود.
  • من الصعب تذكر الأسماء.
  • يمكن استخدام متغيرات متعددة ذات دلالات مختلفة في كتلة من التعليمات البرمجية بأسماء مماثلة: dwTmp، iTmp، fTmp، dTmp .

آراء بارزة

[عدل]
  • روبرت سيسيل مارتن (ضد التدوين المجري وجميع أشكال الترميز الأخرى):

    ... في الوقت الحاضر، أصبحت HN وأشكال أخرى من ترميز النوع مجرد عوائق. إنها تجعل من الصعب تغيير اسم أو نوع المتغير أو الوظيفة أو العضو أو الفئة. إنهم يجعلون قراءة الكود أكثر صعوبة. وهم يخلقون إمكانية أن يقوم نظام الترميز بتضليل القارئ. [9]

  • لينوس تورفالدز (ضد الأنظمة المجرية):

    إن ترميز نوع الدالة في الاسم (ما يسمى بالترميز المجري) هو تلف في الدماغ - يعرف المترجم الأنواع على أي حال ويمكنه التحقق منها، وهذا فقط يربك المبرمج. [10]

  • ستيف ماكونيل (للتطبيقات المجرية):

    على الرغم من أن اتفاقية التسمية المجرية لم تعد مستخدمة على نطاق واسع، فإن الفكرة الأساسية المتمثلة في توحيد الاختصارات الدقيقة والمقتضبة لا تزال ذات قيمة. تسمح لك البادئات القياسية بالتحقق من الأنواع بدقة عند استخدام أنواع البيانات المجردة التي لا يستطيع المترجم الخاص بك التحقق منها بالضرورة. [11]

  • بيارن ستروستروب (ضد شركة Systems Hungarian لصالح C++):

    لا، لا أوصي بـ "المجري". أعتبر "المجرية" (تضمين نسخة مختصرة من نوع ما في اسم متغير) تقنية يمكن أن تكون مفيدة في اللغات غير المكتوبة، ولكنها غير مناسبة تمامًا للغة تدعم البرمجة العامة والبرمجة الموجهة للكائنات - وكلاهما يؤكد على اختيار العمليات بناءً على النوع والحجج (المعروفة للغة أو لدعم وقت التشغيل). في هذه الحالة، يؤدي "بناء نوع الكائن في أسماء" ببساطة إلى تعقيد وتقليل التجريد. [12]

  • جويل سبولسكي (للتطبيقات المجرية):

    إذا قرأت ورقة سيموني عن كثب، فسوف تجد أنه كان يقصد نفس نوع اتفاقية التسمية التي استخدمتها في مثالي أعلاه حيث قررنا أن us تعني سلسلة غير آمنة وأن s تعني سلسلة آمنة. كلاهما من نوع string . لن يساعدك المترجم إذا قمت بتعيين أحدهما إلى الآخر ولن يخبرك Intellisense [نظام إكمال الكود الذكي ] bupkis . لكنهم مختلفون دلاليا. يجب تفسيرها ومعالجتها بشكل مختلف، وسيتعين استدعاء نوع ما من وظيفة التحويل إذا قمت بتعيين أحدهما إلى الآخر أو سيكون لديك خطأ في وقت التشغيل. إذا كنت محظوظا. لا يزال هناك قدر هائل من القيمة في Apps Hungarian، حيث إنها تزيد من الترابط في الكود، مما يجعل الكود أسهل في القراءة والكتابة والتصحيح والصيانة، والأهم من ذلك، أنها تجعل الكود الخاطئ يبدو خاطئًا.... (الأنظمة المجرية) كان سوء فهم خفيًا ولكنه كامل لنية سيموني وممارساته. [13]

  • تثني إرشادات تصميم Microsoft [14] المطورين عن استخدام نظام التدوين المجري عند اختيار أسماء العناصر في . مكتبات فئة NET، على الرغم من أنها كانت شائعة على منصات تطوير Microsoft السابقة مثل Visual Basic 6 والإصدارات الأقدم. لا تتضمن إرشادات التصميم هذه أي شيء بشأن اتفاقيات التسمية للمتغيرات المحلية داخل الوظائف.

انظر أيضًا

[عدل]
  • اتفاقية تسمية Leszynski ، وهي أحد أشكال اللغة المجرية لتطوير قواعد البيانات
  • حالة الجمل ، وهي تسمية أخرى واسعة الانتشار
  • التدوين البولندي ، مفهوم غير ذي صلة يحمل اسمًا مشابهًا

المراجع

[عدل]
  1. ^ "Oral History of Charles Simonyi" (PDF). Archive.computerhistory.org\accessdate=5 August 2018. مؤرشف (PDF) من الأصل في 2015-09-10.
  2. ^ Rosenberg, Scott (1 Jan 2007). "Anything You Can Do, I Can Do Meta". MIT Technology Review (بالإنجليزية). Archived from the original on 2025-05-03. Retrieved 2022-07-21.
  3. ^ Charles Simonyi (نوفمبر 1999). "Hungarian Notation". MSDN Library. Microsoft Corp. مؤرشف من الأصل في 2008-10-11.
  4. ^ ا ب Spolsky، Joel (11 مايو 2005). "Making Wrong Code Look Wrong". Joel on Software. مؤرشف من الأصل في 2016-11-22. اطلع عليه بتاريخ 2005-12-13.
  5. ^ ا ب Charles Simonyi (نوفمبر 1999). "Hungarian Notation". MSDN Library. Microsoft Corp. مؤرشف من الأصل في 2008-10-11.Charles Simonyi (November 1999).
  6. ^ "Mozilla Coding Style". Developer.mozilla.org. مؤرشف من الأصل في 2019-12-02. اطلع عليه بتاريخ 2015-03-17.
  7. ^ "Webkit Coding Style Guidelines". Webkit.org. مؤرشف من الأصل في 2015-11-28. اطلع عليه بتاريخ 2015-03-17.
  8. ^ Jones، Derek M. (2009). The New C Standard: A Cultural and Economic Commentary (PDF). Addison-Wesley. ص. 727. ISBN:978-0-201-70917-9. مؤرشف (PDF) من الأصل في 2011-05-01.
  9. ^ Martin، Robert Cecil (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Redmond, WA: Prentice Hall PTR. ISBN:978-0-13-235088-4.
  10. ^ "Linux kernel coding style". نواة لينكس documentation. مؤرشف من الأصل في 2025-04-23. اطلع عليه بتاريخ 2018-03-09.
  11. ^ McConnell، Steve (2004). Code Complete (ط. 2nd). Redmond, WA: Microsoft Press. ISBN:0-7356-1967-0.
  12. ^ Stroustrup، Bjarne (2007). "Bjarne Stroustrup's C++ Style and Technique FAQ". مؤرشف من الأصل في 2025-05-15. اطلع عليه بتاريخ 2015-02-15.
  13. ^ Spolsky، Joel (11 مايو 2005). "Making Wrong Code Look Wrong". Joel on Software. مؤرشف من الأصل في 2016-11-22. اطلع عليه بتاريخ 2005-12-13.Spolsky, Joel (2005-05-11).
  14. ^ "Design Guidelines for Developing Class Libraries: General Naming Conventions". مؤرشف من الأصل في 2008-08-21. اطلع عليه بتاريخ 2008-01-03.

روابط خارجية

[عدل]
مجلوبة من «https://ar.wikipedia.org/w/index.php?title=التدوين_الهنغاري&oldid=70984622»