سؤال

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

انظر أيضا: الناس استخدام الهنغارية تسمية الاتفاقيات في العالم الحقيقي ؟

هل كانت مفيدة؟

المحلول

معظم الناس استخدام منهج المجرية بطريقة خاطئة و يتم الحصول على نتائج خاطئة.

قراءة هذا المقال الممتاز جويل سبولسكي: مما يجعل رمز الخطأ نظرة خاطئة.

باختصار منهج المجرية حيث كنت البادئة الخاصة بك أسماء المتغيرات مع type (سلسلة) (نظم المجرية) هو سيء لأنه عديم الفائدة.

منهج المجرية كما كان المقصود من الكاتب حيث كنت بادئة اسم المتغير مع kind (باستخدام جويل سبيل المثال:آمنة سلسلة أو غير آمنة سلسلة) ، ما يسمى تطبيقات المجري لها استخدامات لا تزال قيمة.

نصائح أخرى

vUsing adjHungarian nnotation vmakes nreading ncode adjdifficult.

جويل هو خطأ و لماذا هو هنا.

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

الكثير من الأشياء التي جويل المحادثات من "أنواع" ليست أنواعها.هم في الواقع أنواع.

ما أكثر اللغات نقص ، ومع ذلك ، هو نوع النظام الذي معبرة بما فيه الكفاية لفرض هذا النوع من التمييز.على سبيل المثال ، إذا ج نوعا من "قوية typedef" (حيث typedef اسم كل عمليات القاعدة النوع ، ولكن لم تكن قابلة للتحويل إلى ذلك) ثم الكثير من هذه المشاكل سوف تذهب بعيدا.على سبيل المثال, إذا كنت يمكن أن نقول ، strong typedef std::string unsafe_string; لإدخال نوع جديد unsafe_string التي لا يمكن تحويلها إلى std::string (وهكذا يمكن أن المشاركة في الزائد القرار وما إلى ذلك..... الخ) وعندئذ لا حاجة سخيفة البادئات.

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

وبعبارة أخرى ، فإن الهدف لا ينبغي أن يكون "جعل رمز الخطأ نظرة خاطئة إلى المطور".ينبغي أن يكون "جعل رمز الخطأ نظرة خاطئة إلى مترجم".

أعتقد أنه على نطاق واسع المبعثر في التعليمات البرمجية المصدر.

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

منهج المجرية معنى فقط في اللغات دون الأنواع المعرفة من قبل المستخدم.في حديث وظيفية أو OO-اللغة سوف ترميز المعلومات حول "النوع" من قيمة إلى نوع البيانات أو الدرجة وليس في اسم المتغير.

عدة إجابات المرجعية Joels المادة.نلاحظ أن المثال هو في VBScript التي لم تدعم المعرفة من قبل المستخدم الطبقات (لفترة طويلة على الأقل).في اللغة مع الأنواع المعرفة من قبل المستخدم هل من حل نفس المشكلة عن طريق إنشاء HtmlEncodedString نوع ومن ثم السماح أسلوب الكتابة تقبل فقط.في ثابت كتابة اللغة المترجم سوف التقاط أي ترميز-أخطاء في كتابة حيوي سوف تحصل على وقت استثناء - ولكن في أي حال من أنك محمي ضد الكتابة unencoded السلاسل.المجرية الرموز فقط يتحول مبرمج في نوع الإنسان-مدقق ، هو نوع من العمل الذي هو عادة أفضل التعامل معها من خلال البرامج.

جويل يميز بين "أنظمة المجرية" و "تطبيقات المجرية" ، حيث "نظم المجرية" بترميز المدمج في أنواع مثل int, float على "تطبيقات المجرية" يشفر "أنواع" ، وهو أعلى مستوى الفوقية-معلومات عن متغير beyound نوع الجهاز ، OO أو الفنية الحديثة اللغة يمكنك إنشاء أنواع معرفة من قبل المستخدم حتى لا يكون هناك أي تمييز بين نوع و "النوع" في هذا المعنى - على حد سواء يمكن أن تكون ممثلة على حسب نوع النظام و "تطبيقات" المجرية هو مجرد زائدة "نظم" المجرية.

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

تطبيقات المجرية لن يكون له معنى إذا كنت تعمل مع اللغة دون تعريف المستخدم أنواع مثل إرث VBScript أو الإصدارات في وقت مبكر من VB.وربما أيضا الإصدارات في وقت مبكر من Perl و PHP.مرة أخرى باستخدام الأمر في الحديث لغة نقية الطائفة البضائع.

في أي لغة أخرى, الهنغارية هو مجرد قبيحة زائدة الهشة.يكرر المعلومات معروفة من نوع النظام ، يجب أن لا تكرر نفسك.استخدام وصفي اسم المتغير الذي يصف القصد من هذا المثال بالتحديد من نوع.استخدام نوع نظام ترميز الثوابت و المعلومات الوصفية عن "أنواع" أو "الطبقات" من المتغيرات - أي.أنواع.

النقطة العامة من Joels المادة - أن يكون الخطأ نظرة رمز الخطأ - جيد جدا من حيث المبدأ.ومع ذلك أفضل حماية ضد البق - عندما يكون ذلك ممكنا على الإطلاق - يكون رمز الخطأ أن يتم الكشف عن تلقائيا من قبل المترجم.

أنا دائما استخدام منهج المجرية جميع المشاريع.أجد أنه من المفيد حقا عندما أتعامل مع 100s من مختلف معرف أسماء.

على سبيل المثال ، عند استدعاء دالة تتطلب سلسلة أستطيع أن اكتب 's' و ضرب السيطرة على الفضاء و IDE سوف تظهر لي بالضبط أسماء المتغيرات مسبوقة مع 's' .

ميزة أخرى ، عندما البادئة ش موقعة وأنا وقعت رجات ، وعلى الفور نرى أين أنا خلط الموقعة و غير الموقعة في خطرة الطرق.

لا أستطيع أن أتذكر عدد المرات عندما ضخمة 75000 خط codebase, الحشرات تسبب (قبل غيري أيضا) بسبب تسمية المتغيرات المحلية نفس القائمة متغيرات عضو من تلك الفئة.منذ ذلك الحين, أنا دائما البادئة أعضاء 'm_'

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

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

نعم IDE بسرعة تحديد أنواع بالنسبة لك.ومع ذلك ، عندما كنت في القراءة من خلال بعض منذ فترة طويلة دفعات من قواعد عمل مدونة, أنه من الجيد أن لا بد لي من وقفة على كل متغير لمعرفة ما هو نوع.عندما أرى الأشياء مثل strUserID, intProduct أو guiProductID ، فإنه يجعل كثيرا أسهل 'رفع' الوقت.

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

اصطلاحات تسمية الأشياء الجيدة ، شريطة التمسك بها.لقد ذهبت من خلال ما يكفي من القانون القديم الذي كان لي باستمرار العودة إلى النظر في تعريفات كثيرة وبالمثل اسمه المتغيرات التي دفعت "الجمل غلاف" (كما كان يسمى في وظيفة سابقة).الآن أنا في العمل الذي لديه العديد من آلاف الخطوط تماما uncommented الكلاسيكية ASP البرمجية VBScript و انه كابوس أحاول أن الرقم الامور.

تغير اتجاهها على خفي الشخصيات في بداية كل اسم المتغير هو لا لزوم لها ويظهر أن اسم المتغير في حد ذاته ليس وصفي بما فيه الكفاية.معظم اللغات تتطلب نوع المتغير في الإعلان على أي حال ، حتى أن المعلومات المتاحة بالفعل.

هناك أيضا الحالة التي يكون فيها ، أثناء الصيانة ، متغير نوع يحتاج إلى تغيير.على سبيل المثال:إذا كان المتغير كما أعلن "uint_16 u16foo" يجب أن تصبح 64 بت غير موقعة أحد أمرين سيحدث:

  1. عليك أن تذهب من خلال تغيير كل اسم المتغير (التأكد من عدم الخرطوم أي علاقة المتغيرات تحمل نفس الاسم) ، أو
  2. فقط تغيير نوع و لا تغيير الاسم الذي سوف يسبب الارتباك.

جويل سبولسكي كتب جيدة بلوق وظيفة حول هذا الموضوع.http://www.joelonsoftware.com/articles/Wrong.html يتعلق الأمر أساسا إلى أسفل أن لا يجعل التعليمات البرمجية الخاصة بك أكثر صعوبة القراءة عند لائق IDE سوف اقول كنت تريد نوع المتغير إذا كنت لا تستطيع تذكر.أيضا, إذا كنت تجعل النظام الخاص بك رمز مجزأة بما فيه الكفاية, لم يكن لديك أن نتذكر ما متغير كما أعلن ثلاثة صفحات.

أليس نطاق أكثر أهمية من نوع هذه الأيام مثلا ،

* l for local
* a for argument
* m for member
* g for global
* etc

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

لا يوجد أي سبب لماذا يجب أن لا تجعل الصحيح استخدام منهج المجرية.انها شعبية يرجع إلى فترة طويلة إلى الوراء-السوط ضد سوء استخدام من منهج المجرية ، وخاصة في Windows Api.

في سوء القديمة أيام ، قبل أي شيء يشبه IDE موجودة DOS (الاحتمالات لم يكن لديك ذاكرة حرة كافية لتشغيل المترجم تحت ويندوز ، لذلك تم تطوير في DOS) لم تحصل على أي مساعدة من تحوم الماوس فوق اسم متغير.(على افتراض لديك الماوس.) ماذا هل لديك للتعامل مع الحدث دالات رد الاتصال التي كان كل شيء مرت عليك إما 16-بت الباحث (كلمة) أو 32 بت الباحث (كلمة طويلة).ثم كان أن يلقي تلك المعلمة إلى الأنواع المناسبة من أجل إعطاء نوع الحدث.في الواقع, الكثير من API تقريبا نوع أقل.

نتيجة, API مع المعلمة أسماء مثل هذه:

LRESULT CALLBACK WindowProc(HWND hwnd,
                            UINT uMsg,
                            WPARAM wParam,
                            LPARAM lParam);

لاحظ أن أسماء wParam و lParam ، على الرغم من أن فظيعة جدا ، ليست حقا أي أسوأ من تسمية لهم param1 و param2.

لجعل الأمور أسوأ, نافذة 3.0/3.1 نوعين من المؤشرات ، القريبة والبعيدة.لذا ، على سبيل المثال ، إعادة قيمة من وظيفة إدارة الذاكرة LocalLock كان PVOID ، ولكن قيمة الإرجاع من GlobalLock كان LPVOID (مع 'L' لفترة طويلة).النكراء التي التدوين ثم حصلت الموسعة بحيث long pointer السلسلة كانت مسبوقة lp, وتمييزه عن سلسلة ببساطة كانت malloc تريد.

فإنه ليس من المستغرب أنه كان هناك رد فعل عنيف ضد هذا النوع من الشيء.

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

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

ومن ناحية أخرى ، يمكن أن تكون هناك حالات حيث حتى وقت التحويل البرمجي نوع التحقق اللغات سوف تستفيد من منهج المجرية -- الفراغ مؤشرات أو التعامل مع's في win32 API.هذه ويعتم الفعلية نوع البيانات, و قد يكون هناك ميزة استخدام منهج المجرية هناك.ومع ذلك ، إذا كان أحد يمكن معرفة نوع البيانات في وقت البناء لماذا لا تستخدم نوع البيانات المناسب.

بشكل عام, لا يوجد صعوبة في أسباب عدم استخدام منهج المجرية.انها مسألة من يحب والسياسات أسلوب الترميز.

كما الثعبان مبرمج, منهج المجرية تنهار بسرعة.في بيثون ، أنا لا أهتم إذا كان هناك شيء هو سلسلة - لا تهتم إذا كان يمكن أن تتصرف مثل سلسلة (أيإذا كان لديه ___str___() الطريقة التي تقوم بإرجاع سلسلة).

على سبيل المثال, دعونا نقول لدينا فو صحيحا ، 12

foo = 12

منهج المجرية يقول لنا أننا يجب أن ندعو أن iFoo أو شيئا للدلالة على انه عدد صحيح ، بحيث في وقت لاحق ، ونحن نعلم ما هو عليه.إلا في بيثون ، هذا لا يعمل, أو بالأحرى لا معنى له.في بيثون ، لقد تقرر ما هو نوع أريد عندما كنت استخدامها.لا أريد سلسلة ؟ حسنا إذا كنت تفعل شيئا مثل هذا:

print "The current value of foo is %s" % foo

ملاحظة %s - سلسلة.فو ليست سلسلة ، ولكن % مشغل الاتصال foo.___str___() واستخدام النتيجة (على افتراض وجوده). foo لا يزال عدد صحيح ، ولكن علينا التعامل معها على أنها سلسلة إذا كنا نريد السلسلة.إذا كنا نريد تعويم ، ثم يمكننا التعامل معها على أنها تطفو.في كتابة حيوي لغات مثل بايثون ، الهنغارية التدوين لا طائل لأنه لا يهم ما هو نوع شيء حتى يمكنك استخدامه, و إذا كنت بحاجة إلى نوع معين, ثم تأكد من أن يلقي هذا النوع (على سبيل المثال float(foo)) عند استخدامه.

علما بأن ديناميكية لغات مثل PHP لا يكون هذا الاستحقاق - PHP يحاول القيام بالشيء الصحيح في الخلفية على أساس غامضة مجموعة من القواعد أن لا أحد تقريبا قد حفظت ، والتي غالبا ما تكون النتائج كارثية عبث بشكل غير متوقع.في هذه الحالة نوعا من تسمية آلية, مثل $files_count أو $file_name, ، يمكن أن تكون في متناول اليد.

في رأيي, Hungarian Notation مثل العلق.ربما في الماضي كانت مفيدة أو على الأقل يبدو أنها مفيدة ، ولكن في الوقت الحاضر هناك الكثير من اضافية الكتابة على الكثير من الفوائد.

IDE أن أنقل هذه المعلومات المفيدة.المجرية قد جعلت نوعا ما (ليس هناك الكثير كله ، ولكن نوعا) من معانيها عندما IDE كانت أقل تقدما.

تطبيقات الهنغارية اليونانية لي بطريقة جيدة

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

Newton's Universal law of gravity for Earth and Mars

frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)

في ملاحظه الرياضية ، أبرز الرموز التي تمثل نوع المعلومات المخزنة في المتغير:القوة والكتلة موقف ناقلات, الخ.على النحو تلعب دورا ثانويا إلى توضيح:موقف ما ؟ هذا هو بالضبط ما تطبيقات الهنغارية هو به ؛ انها تقول لك نوع من الأشياء المخزنة في المتغير الأول ومن ثم الدخول في التفاصيل-عن أقرب رمز يمكن الحصول على المفاهيم الرياضية.

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

على رأس كل ذلك ، الكثير من الهندسة هو معمول به في المكتوبة ضعيف اللغات عالية المستوى مثل Matlab, أو القديمة مثل Fortran 77 أو ادا.

حتى إذا كان لديك اللغة يتوهم IDE و تطبيقات الهنغارية لا تساعدك ثم ننسى ذلك-الكثير من الناس على ما يبدو.لكن بالنسبة لي أسوأ من مبرمج مبتدئ الذي يعمل في ضعيف أو كتابة حيوي لغات, أستطيع أن أكتب أفضل البرمجية بشكل أسرع مع تطبيقات المجرية من دون.

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

زائد -- لي -- انها مجرد مزعج أن ترى إنتي, strUserName ، إلخ.:)

إذا كنت تشعر بأن المعلومات المفيدة وتنظم لماذا لا ينبغي وضعه هناك حيث انها متوفرة ؟

ثم من يهتم أي شخص آخر ما يفكر ؟ إذا كنت تجد أنه من المفيد ، ثم استخدام التدوين.

Im تجربتي أنها سيئة لأن:

1 - إذا كنت كسر كافة التعليمات البرمجية إذا كنت بحاجة إلى تغيير نوع المتغير (أيإذا كنت بحاجة إلى توسيع 32 بت عدد صحيح إلى 64 بت integer);

2 - هذه المعلومات عديمة الفائدة وكذلك نوع إما بالفعل في الإعلان أو استخدام لغة ديناميكية حيث النوع الفعلي يجب أن لا تكون مهمة جدا في المقام الأول.

وعلاوة على ذلك, مع قبول لغة البرمجة العامة (أيوظائف حيث نوع بعض المتغيرات غير تحديد عند كتابة الوظيفة) أو مع ديناميكية نظام الكتابة (أيعندما اكتب حتى لا تحديد في وقت الترجمة), كيف اسمك المتغيرات ؟ و معظم اللغات الحديثة تدعم واحد أو الآخر ، حتى لو كان في تقييد شكل.

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

في الأساس, نظم الهنغارية لا قيمة لها.هو فقط يقول لك نفس الشيء المترجم الخاص بك و/أو IDE سوف اقول لكم.

تطبيقات المجرية يقول لك ما هو متغير من المفترض أن يعني ، يمكن أن تكون في الواقع مفيدة.

لقد اعتقدت دائما أن بادئة أو اثنين في المكان الصحيح لن يضر.أعتقد إذا أنا يمكن أن تضفي شيئا مفيدا مثل "يا هذا هو واجهة لا تعتمد على سلوك معين" هناك ، كما في IEnumerable, أنا يجب أن نفعل ذلك.التعليق يمكن أن فوضى الأشياء أكثر بكثير من مجرد واحد أو اثنين من حرف الرمز.

انها مفيدة اتفاقية تسمية عناصر التحكم الموجودة في نموذج (btnOK, txtLastName الخ) ، إذا كانت قائمة من الضوابط يظهر في أبجديا القائمة المنسدلة في IDE.

أنا أميل إلى استخدام منهج المجرية مع ASP.NET عناصر تحكم الملقم فقط, وإلا أجد أنه من الصعب جدا معرفة ما هي الضوابط ما في النموذج.

خذ هذا مقتطف الشفرة:

<asp:Label ID="lblFirstName" runat="server" Text="First Name" />
<asp:TextBox ID="txtFirstName" runat="server" />
<asp:RequiredFieldValidator ID="rfvFirstName" runat="server" ... />

إذا كان شخص ما يمكن أن تظهر طريقة أفضل من وجود مجموعة من الأسماء دون المجرية كنت تميل إلى الانتقال إلى ذلك.

جويل المادة كبيرة ، ولكن يبدو أن حذف إحدى نقاط رئيسية:

المجرية يجعل معين 'فكرة' (نوع + اسم المعرف) فريدة من نوعها ، أو شبه فريدة من نوعها ، عبر مصدر حتى كبيرة جدا تعليمات البرمجة الأساسية.

هذا أمر مهم بالنسبة رمز الصيانة.هذا يعني أنه يمكنك استخدام حسن رأ' من سطر واحد نص البحث (البقرى ، findstr, 'البحث في جميع الملفات') للعثور على كل ذكر أن 'فكرة'.

لماذا هذا مهم عندما يكون لدينا IDE أن تعرف كيفية قراءة الكود ؟ لأنها ليست جيدة جدا في ذلك حتى الآن.هذا من الصعب أن نرى في صغير codebase, ولكن من الواضح في واحدة كبيرة - عندما 'فكرة' قد ذكر في تصريحات ، ملفات XML, Perl النصوص ، و أيضا في أماكن خارج عنصر تحكم مصدر (وثائق الويكي ، علة قواعد البيانات).

يجب عليك أن تكون حذرا قليلا حتى هنا - على سبيل المثال ، عربون-لصق في C/C++ وحدات الماكرو يمكن إخفاء يذكر المعرف.مثل هذه الحالات يمكن أن تعالج باستخدام الترميز الاتفاقيات ، وعلى أي حال فإنها تميل إلى أن تؤثر سوى أقلية من معرفات في تعليمات البرمجة الأساسية.

P. S.إلى نقطة حول استخدام نوع النظام مقابلالهنغارية - فمن الأفضل أن تستخدم على حد سواء.تحتاج فقط رمز الخطأ أن ننظر إلى الخطأ إذا كان المترجم لا يمسك لك.هناك الكثير من الحالات حيث أنها غير ممكنة لجعل مترجم قبض عليه.ولكن حيث انها من الممكن - نعم ، الرجاء القيام بذلك بدلا من ذلك!

عند النظر في جدوى ، على الرغم من النظر في الآثار السلبية تقسيم أنواع.على سبيل المثالفي C#, تغليف 'int' مع المدمج في نوع له عواقب ضخمة.لذلك فمن المنطقي في بعض الحالات ولكن ليس في كل منهم.

فضح فوائد من منهج المجرية

  • فإنه يوفر وسيلة التمييز بين المتغيرات.

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

  • يجعل رمز أكثر قابلية للقراءة.

لقد وجدت أن منهج المجرية يجعل الناس كسالى مع أسماء المتغيرات.لديهم شيء لتمييزه من قبل و هم لا يشعرون بالحاجة إلى توضيح أن الغرض منه.هذا هو ما سوف تجد عادة في المجري رمز رمز مقابلالحديث:sSQL مقابلgroupSelectSql (أو عادة لا sSQL على الإطلاق لأنه من المفترض أن يكون استخدام ORM التي وضعت في وقت سابق من قبل المطورين.), sValue مقابلformCollectionValue (أو عادة لا sValue إما لأنهم يحدث أن تكون في MVC و ينبغي استخدام نموذج ملزمة الميزات), ستيبي مقابلpublishSource ، إلخ.

لا يمكن قراءة.أرى أكثر sTemp1, sTemp2...sTempN من أي hungarianed VB6 بقايا من الجميع جنبا إلى جنب.

  • ويمنع الأخطاء.

هذا من شأنه أن يكون بحكم عدد 2 التي هي كاذبة.

في كلمات السيد:

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

قراءة مثيرة للاهتمام ، كالعادة.

مقتطفات:

"شخص ما, في مكان ما, قراءة سيموني ورقة ، حيث استخدمت كلمة "نوع" و يعتقد انه يعني نوع ، مثل الطبقة ، مثل نوع النظام ، مثل نوع التحقق من أن المترجم لا.انه لم يفعل ذلك.وأوضح بعناية فائقة بالضبط ما هو المقصود من كلمة "نوع" ، ولكن هذا لم يساعد.تم القيام به الضرر."

"ولكن لا يزال هناك كمية هائلة من القيمة إلى تطبيقات المجرية في أنه يزيد التجميع في التعليمات البرمجية ، مما يجعل رمز أسهل في القراءة, الكتابة, التصحيح, والحفاظ, و, والأهم من ذلك أنه يجعل رمز الخطأ نظرة خاطئة".

تأكد من أن لديك بعض الوقت قبل قراءة جويل على البرنامج.:)

عدة أسباب:

  • أي حديث IDE سوف تعطيك نوع المتغير ببساطة تحوم الماوس فوق متغير.
  • معظم اكتب أسماء هي طريقة طويلة (اعتقد HttpClientRequestProvider) أن تكون معقولة تستخدم البادئة.
  • نوع المعلومات لا تحمل صحيح معلومات هو فقط مقتبسا من تعريف متغير بدلا من تحدد الغرض المتغير (اعتقد myInteger مقابل pageSize).

لا أعتقد أن كل من هو متطرف ضد ذلك.في اللغات دون ثابتة أنواع انها مفيدة جدا.أنا بالتأكيد أفضل عندما تستخدم لإعطاء معلومات غير موجودة في النوع.في مثل C ، شار * szName يقول أن متغير يشير إلى null إنهاء سلسلة ... هذا ليس ضمنا في شار* -- بالطبع ، typedef من شأنه أن يساعد أيضا.

كان جويل كبيرة من المادة على استخدام المجرية إلى معرفة ما إذا كان المتغير HTML ترميز أو لا:

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

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

بالطبع عندما 99% من المبرمجين نتفق على شيء, هناك شيء خاطئ.والسبب أنها توافق هنا لأن معظمهم لم تستخدم منهج المجرية بشكل صحيح.

للحصول على معلومات مفصلة الحجة, أود أن أشير إلى بلوق وظيفة لدي عن هذا الموضوع.

http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html

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

بعد حين أدركت أنه عندما تم القيام به بشكل صحيح فإنه لم يساعد فعلا في هذه الأيام و أنا أحب ذلك.

ولكن مثل كل الأشياء الجيدة ، فإنه قد يمكن تعلمها وفهمها والقيام بذلك بشكل صحيح يتطلب بعض الوقت.

المجرية التدوين كان يساء استخدامها ، خاصة من قبل مايكروسوفت ، مما يؤدي إلى البادئات أطول من اسم المتغير, و يظهر ذلك جامدة جدا, وخاصة عند تغيير أنواع (سيئة السمعة lparam/wparam, من نوع مختلف/الحجم في Win16 ، متطابقة في Win32).

وهكذا ، سواء بسبب هذا الاعتداء ، واستخدامها من قبل M$, تم وضعه أسفل كما عديمة الفائدة.

في العمل, نحن البرمجية في جافا ، ولكن مؤسس جاء من MFC العالم ، وذلك باستخدام تعليمة برمجية مشابهة أسلوب (الانحياز الأقواس, أنا أحب هذا!, عواصم طريقة أسماء, أنا معتاد على ذلك ، بادئة مثل m_ إلى أعضاء الفئة (الحقول) ، s_ إلى أعضاء ثابتة ، إلخ.).

وقالوا كل المتغيرات يجب أن يكون بادئة يظهر نوع (على سبيل المثال.أ BufferedReader يدعى brData).التي أظهرت بأنها فكرة سيئة ، أنواع يمكن أن تتغير ولكن الأسماء لا تتبع أو المبرمجون لا تتفق في استخدام هذه البادئات (حتى أرى aBuffer, theProxy ، وما إلى ذلك!).

انا شخصيا اختار بعض البادئات أن أجد من المفيد ، أهمها ب أن البادئة منطقية المتغيرات ، كما أنها هي الوحيدة حيث لا تسمح الجملة مثل if (bVar) (لا فائدة من autocast من بعض القيم إلى true أو false).عندما مشفرة في ج ، كنت بادئة المتغيرات المخصصة مع malloc ، وللتذكير فإنه ينبغي أن يكون الافراج في وقت لاحق.الخ.

لذا أساسا لا نرفض هذا التدوين ككل ، ولكن أخذ ما يبدو من المناسب لاحتياجاتي.
و بالطبع عندما المساهمة في بعض المشاريع (العمل مفتوحة المصدر) ، أنا فقط استخدام الاتفاقيات في المكان!

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top