أمثلة جيدة للتدوين المجري؟ [مغلق

Question

هذا السؤال هو البحث عن أمثلة جيدة للتدوين المجري ، حتى نتمكن من الجمع بين مجموعة من هذه.

يحرر: أوافق على أن الهنغارية لأنواع ليست ضرورية ، آمل أن يكون هناك أمثلة أكثر تحديدًا حيث تزيد من قابلية القراءة والقدرة على الصيانة ، مثل جويل في مقالته (حسب إجابتي).

Answer 1

المقال الكلاسيكي الآن ، كما هو مذكور في المنشورات المجرية الأخرى ، هو المقال من موقع جويل:

http://www.joelonsoftware.com/articles/wrong.html

Answer 2

المشكلة في طلب أمثلة جيدة للتدوين الهنغاري هي أن الجميع سيكون لديهم فكرتهم الخاصة عما يبدو عليه مثال جيد. رأيي الشخصي هو أن الأفضل التدوين المجري هو لا تدوين مجري. كان يهدف الترميز في الأصل إلى الإشارة إلى الاستخدام المقصود من متغير بدلاً من نوعه ولكنه يستخدم عادةً للحصول على معلومات النوع ، خاصة بالنسبة لعناصر التحكم في النماذج (على سبيل المثال ، txtfirstname للحصول على مربع نص للاسم الأول لشخص ما.). هذا يجعل الكود أقل قابلية للصيانة ، من حيث قابلية القراءة (على سبيل المثال ، "prepin nounterms prepof nounreadability") وإعادة إنشاء متى يجب تغيير النوع (هناك "lparams" في واجهة برمجة تطبيقات Win32 التي تغيرت النوع).

ربما يجب أن تفكر في عدم استخدامه على الإطلاق. أمثلة:

• strfirstname - هذا يمكن أن يكون فقط الاسم الاول نظرًا لأنه من الواضح ما هو عليه ، فإن النوع ليس مهمًا ويجب أن يكون واضحًا في هذه الحالة. إذا لم يكن واضحا ، يمكن أن تساعدك IDE في ذلك.
• txtfirstname - هذا يمكن أن يتغير إلى FirstnametextBox أو FirstName_TextBox. إنه يقرأ بشكل أفضل وأنت تعلم أنه عنصر تحكم وليس فقط النص.
• caccount - ج تم استخدامه لأسماء الفصول الدراسية في MFC ولكنك لا تحتاجها حقًا. الحساب هو جيد بما فيه الكفاية. الاسم الكبير هو الاتفاقية القياسية للأنواع (ولا تظهر إلا في أماكن محددة حتى لا يتم الخلط بينها وبين الخصائص أو الأساليب)
• Ixarray (فهرس ل مجموعة مصفوفة) - ix غامض بعض الشيء. محاولة ArrayIndex.
• أوستيت (سلسلة غير آمنة ل حالة) - يشبه "الدولة الأمريكية". من الأفضل الذهاب مع حالة_غير آمن أو شيء ما. ربما حتى لفه في غير آمن الفصل لجعله آمنًا على الأقل.

Answer 3

ص

(للمؤشر). إنها البادئة الوحيدة التي أستخدمها. أعتقد أنه يضيف الكثير إلى متغير (على سبيل المثال أنه مؤشر) وبالتالي يجب أن يعامل باحترام أكثر قليلاً.

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

Answer 4

ر

بيانات ملوثة. بادئة جميع البيانات الواردة من مصدر غير موثوق لجعل هذا المتغير ملوث. يجب تطهير جميع البيانات الملوثة قبل القيام بأي عمل حقيقي عليه.

Answer 5

من غير المجدي استخدام الهنغارية للإشارة إلى الأنواع لأن المترجم يقوم بالفعل بذلك من أجلك.

عندما يكون الهنغارية مفيدًا ، فإن التمييز بين أنواع المتغيرات المختلفة منطقيا التي لها نفس النوع الخام. على سبيل المثال ، إذا كنت تستخدم ints لتمثيل الإحداثيات ، فيمكنك بادئة إحداثيات X مع إحداثيات X و Y مع Y والمسافات مع D. لذلك سيكون لديك رمز يبدو

dxHighlight = xStart - xEnd

yHighlight = yLocation + 3

yEnd = yStart + dyHeight

dyCode = dyField * 2

وهلم جرا. إنه مفيد لأنه يمكنك اكتشاف الأخطاء في لمحة: إذا قمت بإضافة DY إلى AY ، فستحصل دائمًا على Y. إذا قمت بطرح اثنين من X ، فستحصل دائمًا على DX. إذا كنت تضاعف DY بواسطة عددي ، فستحصل دائمًا على DY. وهلم جرا. إذا رأيت خط مثل

yTop = dyText + xButton

أنت تعرف في لمحة أنه من الخطأ لأن إضافة DY و AX لا معنى له. لم يستطع المترجم أن يمسك هذا من أجلك لأنه بقدر ما يمكن أن يقول ، فأنت تضيف int إلى int وهو أمر جيد.

Answer 6

لا تستخدم البادئات الخاصة باللغة.

نحن نستخدم:

n: Number 
p: Percentage 1=100% (for interest rates etc)
c: Currency
s: String
d: date
e: enumeration
o: object (Customer oCustomer=new Customer();)
...

نستخدم نفس النظام لجميع اللغات:

SQL
C
C#
Javascript
VB6
VB.net
...

إنه مدخر للحياة.

Answer 7

محامي الشيطان: أفضل مثال على التدوين المجري هو عدم استخدامه. :د

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

يمكنك أيضًا الدخول في طلب المشكلات مع التدوين. إذا كنت تستخدم P للمؤشر والعنوان ، فهل تتصل بمتغير apstreet أو pastreet؟ تتضاءل قابلية القراءة عندما لا يكون لديك اتساق ، وعليك استخدام مساحة العقل القيمة عندما يتعين عليك تذكر الترتيب الذي يجب عليك كتابة التدوين فيه.

Answer 8

أجد أن التدوين المجري قد يكون مفيدًا في بعض الأحيان في اللغات الديناميكية. أنا أفكر على وجه التحديد في Actionscript Server Side (فقط JavaScript) ، ولكن يمكن أن ينطبق في مكان آخر. نظرًا لعدم وجود معلومات حقيقية على الإطلاق ، يمكن أن يساعد التدوين المجري في بعض الأحيان في جعل الأمور أسهل قليلاً في الفهم.

Answer 9

الهنغاري الوحيد الذي هو مفيد حقًا بعد الآن هو M_ للمتغيرات الأعضاء. (أنا أيضًا أستخدم SM_ للأعضاء الثابتين ، لأن هذا هو النطاق "الآخر" الذي لا يزال موجودًا.) مع شاشات ومراقبات عريضة لا تستحق كل هذا العناء.

Answer 10

التدوين المجري (غلاف الجمل ، كما تعلمته) لا يقدر بثمن عندما ترث مشروع برمجي.

نعم ، يمكنك "التحوم" على متغير مع IDE الخاص بك ومعرفة فئة ما هو عليه ، ولكن إذا كنت ترحيل عدة آلاف من خطوط التعليمات البرمجية ، فأنت لا تريد أن تتوقف عن تلك الثواني القليلة - كل .. .. مرة واحدة....

تذكر - أنت لا تكتب رمزًا لك أو لفريقك بمفردك. أنت أيضًا تكتبه للشخص الذي يتعين عليه التقاط هذا الرمز من 2 إلى 5 سنوات على الطريق وتعزيزه.

Answer 11

كنت ضد التدوين الهنغاري بقوة حتى بدأت حقًا في القراءة حول هذا الموضوع وأحاول أن أفهم قصدها الأصلية.
بعد قراءة Joels Post "خطأ" ومقال "إعادة اكتشاف التدوين المجري" لقد غيرت رأيي حقًا. تم ذلك بشكل صحيح ، فأنا أؤمن أنه يجب أن يكون قويًا للغاية.

مخطئ من جويل سبولسكي
http://www.joelonsoftware.com/articles/wrong.html

إعادة اكتشاف التدوين المجري
http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html

أنا أؤكد أن معظم الرافضين لم يحاولوا ذلك أبدًا ولا يفهمونها حقًا. أحب أن أجربه في مشروع حقيقي.

Answer 12

أعتقد أن الشيء الرئيسي الذي يجب أخذه بعيدًا عن مقال جويل ، المرتبط أعلاه ، والتدوين المجري بشكل عام ، هو استخدامه عندما يكون هناك شيء غير واضحة حول المتغير.

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

Answer 13

م

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

Answer 14

أجد أن النقطة المفيدة الوحيدة هي عند إعلان عناصر التحكم في الواجهة ، txtusername ، txtpassword ، ddlbirthmonth. إنه ليس مثاليًا ، لكنه يساعد على أشكال/مشاريع كبيرة.

لا أستخدمه للمتغيرات أو عناصر أخرى ، فقط عناصر التحكم.

Answer 15

بالإضافة إلى استخدام "P" للمؤشر ، أحب فكرة استخدام "CB" و "CCH" للإشارة إلى ما إذا كانت معلمة حجم المخزن المؤقت (أو المتغير) هي عدد من البايتات أو عدد الأحرف (لقد رأيت أيضًا - نادراً ما تستخدم "CE" للإشارة إلى عدد العناصر). لذا بدلاً من نقل النوع ، تقوم البادئة بنقل استخدام أو نية.

أعترف ، أنا لا أستخدم البادئة باستمرار كما ينبغي على الأرجح ، لكني أحب الفكرة.

Answer 16

أوافق على أن التدوين المجري لم يعد مفيدًا بشكل خاص. اعتقدت أن نيتها الأصلية هي الإشارة إلى نوع البيانات ، بل نوع الكيان. في قسم التعليمات البرمجية الذي يتضمن أسماء العملاء والموظفين والمستخدم ، على سبيل المثال ، يمكنك تسمية اسم Cusname و Empname و USRName. من شأنه أن يساعد في التمييز بين أسماء متغيرات مماثلة. سيتم استخدام نفس البادئات للكيانات في جميع أنحاء التطبيق. ومع ذلك ، عند استخدام OO ، وأنت تتعامل مع الكائنات ، تكون هذه البادئات زائدة عن الحاجة في العميل. name و experiese.name و user.name.

Answer 17

يجب أن يصف اسم المتغير ما هو عليه. تسمية متغيرة جيدة تجعل الترميز الهنغاري عديمة الفائدة.

ومع ذلك ، في بعض الأحيان تستخدم الترميز المجري بالإضافة إلى تسمية متغيرة جيدة. يحتوي M_NUMOBJECTS على "بادئات:" M_ و NUM. م _ يشير إلى النطاق: إنه عضو في البيانات مرتبط به هذه. رقم يشير إلى القيمة هو.

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

لقد تباطأت عندما أقرأ أشياء مثل m_ubscale (نعم ، أنا أنظر إليك يا ليران!) ، بما أنني يجب أن أنظر إلى استخدامه (لا توجد تعليقات!) لمعرفة ما هو موازين (إن كان على الإطلاق؟) وهو نوع البيانات (الذي يحدث ليكون نقطة ثابتة). سيكون اسم أفضل هو m_scalefactor أو m_zoomfactor ، مع تعليق كرقم نقطة ثابتة ، أو حتى typedef. (في الواقع ، سيكون Typedef مفيدًا ، حيث يوجد العديد من الأعضاء الآخرين في العديد من الفئات التي تستخدم نفس تنسيق النقطة الثابتة. ومع ذلك ، فإن بعضها لا ، ولكن لا يزال يسمى m_ubwhance! مربك ، على أقل تقدير.)

أعتقد أن الهنغاري كان من المفترض أن يكون مضافة للاسم المتغير ، وليس بديلاً للمعلومات. أيضا ، في كثير من الأحيان لا يضيف التدوين المجري أي شيء على الإطلاق إلى قابلية قراءة المتغير ، وإهدار البايتات ووقت القراءة.

فقط بلدي 2 ¢.

Answer 18

سؤال قديم للغاية ، ولكن إليك بادئات "الهنغارية" التي أستخدمها بانتظام:

لي

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

myStart = GetTime();
doComplicatedOperations();
print (GetTime() - myStart);

و

TMP

للحصول على نسخ مؤقتة من القيم في الحلقات أو العمليات متعددة الخطوات. إذا رأيت متغيرين TMPFOO أكثر من خطين من بعضهما البعض ، فمن المؤكد أنهما لا علاقة لهم.

tmpX = X; 
tmpY = Y;
X = someCalc(tmpX, tmpY);
Y = otherCalc(tmpX, tmpY);

وأحيانا قديم و الجديد في لأسباب مماثلة ل TMP, ، عادة في حلقات أو وظائف أطول.

Answer 19

أنا فقط أستخدم P للمؤشر ، وهذا كل شيء. وهذا فقط إذا كنت في C ++. في C# لا أستخدم أي تدوين مجري. على سبيل المثال

MyClass myClass;
MyClass* pMyClass;

هذا كل شئ :)

يحرر: أوه ، لقد أدركت أن هذه كذبة. أستخدم "M_" للمتغيرات الأعضاء أيضًا. على سبيل المثال

class
{
private:
bool m_myVar;
}

Answer 20

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

Answer 21

لا يوجد شيء مثل مثال جيد على التدوين المجري. فقط لا تستخدمه. ولا حتى لو كنت تستخدم لغة مكتوبة ضعيفة. ستعيش أكثر سعادة.

ولكن إذا كنت بحاجة حقًا إلى بعض الأسباب لعدم استخدامه ، فهذا هو المفضل لدي ، مستخرج منه هذا الرابط العظيم:

خدعة متابعة واحدة في التدوين الهنغاري هي "تغيير نوع المتغير ولكن اترك الاسم المتغير دون تغيير". يتم ذلك دائمًا تقريبًا في تطبيقات Windows مع الترحيل من Win16:- Wndproc (Hwnd HW ، Word WMSG ، Word Wparam ، Long lparam) إلى Win32 Wndproc (Hwnd HW ، Uint WMSG ، Wparam Wparam ، Lparam lparam) حيث تعرّف قيمة W) أنها كلمات ، لكنها تشير حقا إلى الطول. تأتي القيمة الحقيقية لهذا النهج واضحة مع ترحيل Win64 ، عندما تكون المعلمات عرضها 64 بت ، لكن البادئات القديمة "W" و "L" ستبقى إلى الأبد.

Answer 22

أجد نفسي أستخدم "W" معنى "العمل" ، كبادئة بدلاً من "Temp" أو "TMP" ، للمتغيرات المحلية الموجودة فقط لبيانات الفارس حولها ، مثل:

Public Function ArrayFromDJRange(rangename As Range, slots As Integer) As Variant

' this function copies a Disjoint Range of specified size into a Variant Array 7/8/09 ljr

Dim j As Integer
Dim wArray As Variant
Dim rCell As Range

wArray = rangename.Value ' to initialize the working Array
ReDim wArray(0, slots - 1) ' set to size of range
j = 0

For Each rCell In rangename
    wArray(0, j) = rCell.Value
    j = j + 1
Next rCell

ArrayFromDJRange = wArray

End Function