هل ينطبق التدوين الهنغاري على لغة Perl؟[مغلق]

Question

في لغة Perl، الإشارة إلى أي شيء هي عددية بسيطة، ولها $ سيجيل.من الصعب أحيانًا تحديد نوع المرجع.

أنا شخصياً أسبق أسماء المتغيرات للمراجع بحرف يشير إلى نوع المرجع.أمثلة:

my $aValues = [];                # arrayref
my $hValue  = {};                # hashref
my $oValue  = bless {};          # object
my $sValue  = \(my $s = 'foo');  # scalarref
...

لقد رأيت كلا من المؤيدين والمعارضين لمثل هذا التدوين.هل تستعملها؟هل لديها أي عيوب؟

Answer 1

أنا شخصياً أجد أن التدوين المجري يصعب قراءته. أنا فقط استخدم الاتفاقيات الإنجليزية:

my $values; # is an array
my $value;  # is a scalar
my $value_hash; # is a hash

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

my $value_obj;  # is an object

Answer 2

مه. لا ينتهي الأمر بـ ArrayRefs و Hashrefs وما شابه ذلك إلى أن تربك هنا أن القضية تظهر في كثير من الأحيان من نوع perl-data. (ايضا: $oValue؟ كيف يمكن أن تكون عاما؟ أي نوع من الكائن هو؟)

أعطني الوحدات الدلالية التدوين المجري بدلاً من ذلك: $size_bits, $size_bytes, $size_kb, $size_blocks, $size_mb, $size_gb. نوع البيانات الأساسي؟ ليس بنفس أهمية إضافة 3 بايت إلى 10 ميغابايت في الثانية والحصول على 13. الذي - التي هو المكان الذي يكون فيه التدوين المجري لبعض الشكل مفيدًا.

Answer 3

إذا كنت تريد اللغات المكتوبة بشكل ثابت ، فأنت تعرف مكان العثور عليها ...

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

Answer 4

الغرض من التدوين المجري هو تضمين التعليقات التوضيحية الدلالية

• لا يمكن التعبير عنها بطريقة أخرى داخل اللغة، وخاصة نظام الكتابة AND
• لا تظهر من السياق

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

أحد الأمثلة التي يتم الاستشهاد بها كثيرًا للتدوين الهنغاري هو إضافة بادئة لجميع متغيرات السلسلة في التطبيق باستخدام إما s أو u (ل آمن و غير آمن)، اعتمادًا على ما إذا كانت السلسلة جاءت من مصدر موثوق به (أو تم تطهيرها) أو من مصدر غير موثوق به.لكن:فقط استبدل غير آمن مع ملوث ولديك وصف مثالي للتلوث في بيرل.لذلك، في هذه الحالة، على الرغم من أن لغة Perl لا تحتوي على نظام كتابة ثابت، إلا أنها تحتوي على متحرك نظام الكتابة الذي يسمح لك بالتعبير عن دلالات الموثوق به/غير الموثوق به داخل اللغة وبالتالي فإن التدوين المجري غير ضروري.(وحتى في اللغة التي لا تحتوي على دعم مدمج للتلوث، عادةً ما تكون هناك طرق أفضل بكثير، مثل الكتابة الفرعية (Python، Ruby، Smalltalk، ...)، التعليقات التوضيحية/السمات (Java، C#، ...)، البيانات الوصفية (Clojure، ...) والكتابة الثابتة (Haskell، ML، ...).)

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

التسمية الجيدة تساعد أيضًا بالطبع.

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

Answer 5

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

$a->{key};  # hash
... if @$b; # array
$c->foo;    # object

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