هذا هو الأمر perlstyle الذي يمكن تشغيله في مزود الاستضافة المجانية OnWorks باستخدام إحدى محطات العمل المجانية المتعددة على الإنترنت مثل Ubuntu Online أو Fedora Online أو محاكي Windows عبر الإنترنت أو محاكي MAC OS عبر الإنترنت
برنامج:
اسم
بيرل ستايل - دليل أسلوب بيرل
الوصف
سيكون لكل مبرمج ، بالطبع ، تفضيلاته الخاصة فيما يتعلق بالتنسيق ،
ولكن هناك بعض الإرشادات العامة التي ستجعل قراءة برامجك أسهل ،
يفهم ، ويحافظ.
أهم شيء هو تشغيل برامجك تحت -w علم في جميع الأوقات. يمكنك
قم بإيقاف تشغيله بشكل صريح لأجزاء معينة من التعليمات البرمجية عبر "عدم وجود تحذيرات" pragma أو
$ ^ W متغير إذا لزم الأمر. يجب أيضًا أن تعمل دائمًا تحت عنوان "use strict" أو تعرف
لماذا لا. قد يتم إثبات ذلك أيضًا عن طريق "استخدام سيغتراب" وحتى "استخدام التشخيص"
مفيد.
فيما يتعلق بجماليات تخطيط الكود ، فإن الشيء الوحيد الذي يهتم به لاري بشدة هو
أن قوس الإغلاق المتعرج لـ BLOCK متعدد الأسطر يجب أن يتماشى مع الكلمة الأساسية التي
بدأ البناء. علاوة على ذلك ، لديه تفضيلات أخرى ليست قوية جدًا:
· مسافة بادئة من 4 أعمدة.
فتح مجعد على نفس السطر ككلمة رئيسية ، إذا كان ذلك ممكنا ، وإلا يصطفون.
· مسافة قبل فتح مجعد لكتلة متعددة الخطوط.
قد يتم وضع BLOCK من سطر واحد في سطر واحد ، بما في ذلك curlies.
· لا توجد مسافة قبل الفاصلة المنقوطة.
· حذفت الفاصلة المنقوطة في سطر واحد "قصير" BLOCK.
· الفضاء حول معظم المشغلين.
· مسافة حول خط منخفض "معقد" (بين قوسين).
· سطور فارغة بين الأجزاء التي تقوم بأشياء مختلفة.
· إلسس غير محتضن.
· لا توجد مسافة بين اسم الوظيفة وقوس الفتح الخاص بها.
· مسافة بعد كل فاصلة.
· طوابير طويلة مقطوعة بعد عامل (باستثناء "و" و "أو").
· مسافة بعد مطابقة الأقواس الأخيرة على السطر الحالي.
· قم بمحاذاة العناصر المقابلة عموديًا.
احذف علامات الترقيم الزائدة طالما أن الوضوح لا يتأثر.
لدى لاري أسبابه لكل من هذه الأشياء ، لكنه لا يدعي أن الآخرين هم
يعمل العقل بنفس طريقة عمله.
فيما يلي بعض مشكلات الأسلوب الأكثر جوهرية التي يجب التفكير فيها:
· فقط لأنك أنت CAN أن تفعل شيئًا بطريقة معينة لا يعني أنك ينبغي تفعل ذلك
من ذلك الطريق. صُممت لغة Perl لتوفر لك عدة طرق لفعل أي شيء ، لذا ضع في اعتبارك
اختيار الأكثر قراءة. على سبيل المثال
مفتوح (FOO، $ foo) || يموت "لا يمكن فتح $ foo: $!" ؛
أفضل من
يموت "لا يمكن فتح $ foo: $!" ما لم يكن مفتوحًا (FOO، $ foo) ؛
لأن الطريقة الثانية تخفي النقطة الرئيسية للبيان في معدل. على ال
يد أخرى
طباعة "بدء التحليل \ n" إذا $ مطول؛
أفضل من
$ مطول && طباعة "بدء التحليل \ n"؛
لأن النقطة الأساسية ليست ما إذا كان المستخدم قد كتب أم لا -v أم لا.
وبالمثل ، فإن مجرد السماح لك عامل التشغيل بافتراض الوسيطات الافتراضية لا يعني ذلك
أنه يتعين عليك الاستفادة من الإعدادات الافتراضية. توجد الإعدادات الافتراضية للأنظمة البطيئة
المبرمجين الذين يكتبون برامج لقطة واحدة. إذا كنت تريد أن يكون برنامجك قابلاً للقراءة ،
النظر في توفير الحجة.
على نفس المنوال ، فقط لأنك CAN حذف الأقواس في العديد من الأماكن لا يفعل ذلك
يعني أنه يجب عليك:
عودة طباعة عكس عدد قيم الفرز٪ مجموعة؛
عودة الطباعة (عكسي (عدد الفرز (القيم (مجموعة٪)))) ؛
عندما تكون في شك ، ضع بين قوسين. على الأقل سيسمح لبعض المسكين بالارتداد
على مفتاح٪ في vi.
حتى لو لم تكن في شك ، فكر في الرفاهية العقلية للشخص الذي يجب أن يفعل ذلك
احتفظ بالشفرة بعدك ، ومن المحتمل أن يضع الأقواس في المكان الخطأ.
· لا تذهب من خلال التواءات سخيفة للخروج من حلقة في الأعلى أو الأسفل ، عند Perl
يوفر عامل التشغيل "الأخير" حتى تتمكن من الخروج في المنتصف. مجرد "التفوق" عليه أ
القليل لجعله أكثر وضوحا:
خط:
ل (؛؛) {
صياغات؛
LINE الأخير إذا $ foo؛
السطر التالي إذا / ^ # / ؛
صياغات؛
}
· لا تخف من استخدام تسميات الحلقات - فهي موجودة لتحسين إمكانية القراءة بالإضافة إلى
السماح بفواصل حلقة متعددة المستويات. انظر المثال السابق.
· تجنب استخدام "grep ()" (أو "map ()") أو "backticks" في سياق فارغ ، أي عندما
مجرد التخلص من قيم عودتهم. كل هذه الوظائف لها قيم إرجاع ، لذا استخدم
معهم. بخلاف ذلك ، استخدم حلقة "foreach ()" أو وظيفة "system ()" بدلاً من ذلك.
· لإمكانية النقل ، عند استخدام ميزات قد لا يتم تنفيذها على كل جهاز ،
اختبر البنية في EVAL لمعرفة ما إذا كانت قد فشلت. إذا كنت تعرف ما هو الإصدار أو
تم تطبيق patchlevel على ميزة معينة ، يمكنك اختبار $] ($ PERL_VERSION بتنسيق
"الإنجليزية") لمعرفة ما إذا كان سيكون هناك. ستتيح لك وحدة "التكوين" أيضًا
استجواب القيم التي يحددها ضبط البرنامج عندما تم تثبيت Perl.
اختيار المعرفات ذاكري. إذا كنت لا تستطيع تذكر معنى ذاكري ، فلديك ملف
المشكلة.
· بينما ربما تكون المعرفات القصيرة مثل $ gotit جيدة ، استخدم الشرطة السفلية للفصل بين الكلمات
في المعرفات الأطول. من الأسهل عمومًا قراءة $ var_names_like_this من
VarNamesLikeThis $ ، خاصة لغير الناطقين باللغة الإنجليزية. إنها أيضًا بسيطة
القاعدة التي تعمل باستمرار مع "VAR_NAMES_LIKE_THIS".
أحيانًا تكون أسماء الحزم استثناء لهذه القاعدة. تحتفظ بيرل بشكل غير رسمي
أسماء الوحدات الصغيرة للوحدات النمطية "pragma" مثل "عدد صحيح" و "صارم". آخر
يجب أن تبدأ الوحدات النمطية بحرف كبير وأن تستخدم حالة مختلطة ، ولكن ربما بدونها
تسطير أسفل السطر بسبب القيود في تمثيلات أنظمة الملفات البدائية للوحدة
أسماء كملفات يجب أن تتناسب مع عدد قليل من البايتات المتفرقة.
· قد تجد أنه من المفيد استخدام حالة الأحرف للإشارة إلى نطاق أو طبيعة ملف
عامل. على سبيل المثال:
ثوابت ALL_CAPS_HERE $ فقط (احذر من الاشتباكات مع perl vars!)
Some_Caps_Here عالمي / ثابت على مستوى الحزمة
نطاق الدالة no_caps_here $ () أو المتغيرات المحلية ()
يبدو أن أسماء الوظائف والطرق تعمل بشكل أفضل مثل كل الأحرف الصغيرة. على سبيل المثال ،
"obj-> as_string () $".
يمكنك استخدام شرطة سفلية بادئة للإشارة إلى أن المتغير أو الوظيفة لا يجب أن تكون كذلك
تستخدم خارج الحزمة التي حددتها.
· إذا كان لديك تعبير منتظم مشعر حقًا ، فاستخدم المعدل "/ x" وقم بوضع البعض
مسافة بيضاء لجعلها تبدو أقل شبهاً بضوضاء الخطوط. لا تستخدم الشرطة المائلة كملف
المحدد عندما يحتوي التعبير العادي الخاص بك على خطوط مائلة أو مائلة للخلف.
· استخدم عامل التشغيل الجديد "and" and "or" لتجنب الاضطرار إلى حصر عوامل تشغيل القائمة بين أقواس
كثيرًا ، ولتقليل حدوث عوامل الترقيم مثل "&&" و "||". مكالمة
الإجراءات الفرعية الخاصة بك كما لو كانت وظائف أو قائمة المشغلين لتجنب الإفراط
علامات العطف والأقواس.
· استخدم هنا المستندات بدلاً من عبارات "print ()" المتكررة.
· رتب الأشياء المقابلة عموديًا ، خاصةً إذا كانت طويلة جدًا لتناسب أحدها
خط على أي حال.
IDX دولار = ST_MTIME دولار ؛
IDX $ = ST_ATIME $ إذا كان $ opt_u؛
IDX $ = ST_CTIME $ إذا كان $ opt_c؛
IDX دولار = ST_SIZE دولار إذا كان $ opt_s ؛
mkdir $ tmpdir، 0700 or die "لا يمكن mkdir $ tmpdir: $!"؛
chdir ($ tmpdir) أو تموت "لا يمكن chdir $ tmpdir: $!"؛
mkdir 'tmp'، 0777 or die "لا يمكن mkdir $ tmpdir / tmp: $!"؛
· تحقق دائمًا من رموز الإرجاع الخاصة بمكالمات النظام. يجب أن تذهب رسائل الخطأ الجيدة إلى
"STDERR" ، بما في ذلك البرنامج الذي تسبب في حدوث المشكلة ، وما استدعاء النظام الفاشل و
الوسيطات كانت و (مهم جدًا) يجب أن تحتوي على رسالة خطأ النظام القياسية
لما حدث من خطأ. إليك مثال بسيط ولكنه كافٍ:
opendir (D، $ dir) أو يموت "لا يمكن فتح $ dir: $!"؛
· رتب الترجمات الصوتية عندما يكون ذلك منطقيًا:
آر [اي بي سي]
[xyz] ؛
· فكر في قابلية إعادة الاستخدام. لماذا تهدر القوة العقلية في لقطة واحدة بينما قد ترغب في القيام بذلك
شيء من هذا القبيل مرة أخرى؟ ضع في اعتبارك تعميم التعليمات البرمجية الخاصة بك. ضع في اعتبارك كتابة وحدة
أو فئة الكائن. ضع في اعتبارك جعل التعليمات البرمجية تعمل بشكل سليم باستخدام "استخدام صارم" و "استخدام
تحذيرات "(أو -w) في الواقع. النظر في التخلي عن التعليمات البرمجية الخاصة بك. ضع في اعتبارك تغيير ملف
عرض العالم كله. ضع في اعتبارك ... أوه ، لا تهتم.
حاول توثيق التعليمات البرمجية الخاصة بك واستخدام تنسيق Pod بطريقة متسقة. هنا
الاصطلاحات الشائعة المتوقعة:
· استخدم "C <>" لأسماء الوظائف والمتغيرات والوحدات النمطية (وبشكل عام أي شيء
التي يمكن اعتبارها جزءًا من التعليمات البرمجية ، مثل مقابض الملفات أو قيم محددة). ملحوظة
تعتبر أسماء هذه الوظائف أكثر قابلية للقراءة مع وجود أقواس بعدها
الاسم ، وهذا هو "وظيفة ()".
· استخدم "B <>" لأسماء الأوامر مثل قط or البقرى.
· استخدم "F <>" أو "C <>" لأسماء الملفات. يجب أن يكون "F <>" رمز Pod الوحيد للملف
الأسماء ، ولكن نظرًا لأن معظم مُنسِّقات Pod تعرضها كمسارات مائلة ، فإن Unix و Windows بها
قد تكون الخطوط المائلة والخطوط المائلة العكسية أقل قابلية للقراءة وأفضل عرضًا مع
"C <>".
· كن متسقا.
· كن لطيفا.
استخدم perlstyle عبر الإنترنت باستخدام خدمات onworks.net
