ما يجعل كود بيرل للصيانة?

Question

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

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

ما يجعل كود بيرل للصيانة?أو ربما السؤال الأفضل هو ما يجعل كود بيرل من الصعب المحافظة ؟ دعونا نفترض أنني لست الوحيد الذي سيتم الحفاظ على القانون ، وأن المساهمين الآخرين مثلي لا المهنية بيرل المبرمجين ولكن العلماء مع خبرة في البرمجة.

Answer 1

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

• المتغيرات العالمية
• نقص الانفصال عن المخاوف: البرامج النصية المتجانسة
• عدم استخدام معرفات توثيق الذات (أسماء متغيرة وأسماء الأسلوب). على سبيل المثال ، يجب أن تعرف ما هو الغرض من المتغير من اسمه. $c سيئ. $count أفضل. $token_count جيد.
  • تهجئة المعرفات خارج. حجم البرنامج لم يعد مصدر قلق بارز.
  • روتين فرعي أو طريقة تسمى doWork لا يقول أي شيء
  • اجعل من السهل العثور على مصدر الرموز من حزمة أخرى. إما استخدام بادئة الحزمة الصريحة ، أو استيراد صراحة كل رمز يستخدم عبر use MyModule qw(list of imports).
• بيرل خاص:
  • الإفراط في الاعتماد على الاختصارات والمتغيرات المبنية الغامضة
  • إساءة استخدام النماذج الفرعية
  • عدم استخدام strict وعدم استخدام warnings
• إعادة اختراع العجلة بدلاً من استخدام المكتبات القائمة
• عدم استخدام نمط المسافة البادئة المتسقة
• عدم استخدام مساحة بيضاء أفقية ورأسية لتوجيه القارئ

الخ. الخ.

في الأساس ، إذا كنت تعتقد أن بيرل -f>@+?*<.-&'_:$#/%!, ، وتطمح إلى كتابة أشياء من هذا القبيل في رمز الإنتاج ، إذن ، نعم ، سيكون لديك مشاكل.

يميل الناس إلى الخلط بين الأشياء التي يقوم بها مبرمجي Perl من أجل المتعة (على سبيل المثال ، Japhs ، الجولف ، إلخ) مع ما يفترض أن تبدو عليه برامج Perl الجيدة.

ما زلت غير واضح حول كيفية تمكنهم من الانفصال في أذهانهم الشفرة مكتوب ل IOCCC من C.

Answer 2

أقترح:

1. لا تحصل على ذكي للغاية مع بيرل. إذا بدأت تشغيل لعبة الجولف مع الكود ، فسيؤدي ذلك إلى رمز أكثر صعوبة. يجب أن يكون الكود الذي تكتبه قابلاً للقراءة وواضحة أكثر مما يجب أن يكون ذكيًا.
2. توثيق الرمز. إذا كانت وحدة نمطية ، أضف POD تصف الاستخدام والأساليب النموذجية. إذا كان برنامجًا ، أضف POD لوصف خيارات سطر الأوامر والاستخدام النموذجي. إذا كانت هناك خوارزمية شعر ، فقم بتوثيقها وقدم المراجع (عناوين URL) إن أمكن.
3. استخدم الشكل /.../x من التعبيرات العادية ، وتوثيقها. ليس الجميع يفهم regexes جيدا.
4. تعرف ما هو الاقتران ، و Pros/سلبيات الاقتران العالي/المنخفض.
5. تعرف على ما هو التماسك ، وإيجابيات/سلبيات التماسك العالي/المنخفض.
6. استخدام الوحدات النمطية بشكل مناسب. مفهوم لطيف محدد جيدًا ومليء بالحيوية يجعل وحدة رائعة. إعادة استخدام هذه الوحدات هو الهدف. لا تستخدم الوحدات النمطية ببساطة لتقليل حجم برنامج متجانس.
7. اكتب اختبارات الوحدة لك الرمز. لن يسمح لك مجموعة اختبار جيدة فقط بإثبات أن الرمز الخاص بك يعمل اليوم ، ولكن غدًا أيضًا. سيتيح لك أيضًا إجراء تغييرات أكثر جرأة في المستقبل ، بثقة في أنك لا تكسر التطبيقات القديمة. إذا قمت بتكسير الأشياء ، فلن يكون جناح الاختبارات الخاص بك واسعًا بدرجة كافية.

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

Answer 3

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

Answer 4

ما الذي يجعل رمز بيرل يمكن صيانته؟

على الأقل:

use strict;
use warnings;

نرى Perldoc perlstyle بالنسبة لبعض الإرشادات العامة التي ستجعل برامجك أسهل في القراءة وفهمها وصيانتها.

Answer 5

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

بيرل يتيح لك كتابة موجزة جدا البرمجية ، ولكن consise قطع لا يعني أنها يجب أن تكون جميع تتزاحم معا.

المساحة البيضاء لديها الكثير من معنى/يستخدم عندما نتحدث عن القراءة ، ليس كل منهم على نطاق واسع ولكن معظم المفيدة:

• المساحات حول الرموز أسهل منفصلة لهم بصريا.

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

  أجد $myHashRef->{$keys1[$i]}{$keys3{$k}} أن تكون أقل قابلية للقراءة في 2 صباحا في منتصف إنتاجها الطوارئ مقارنة متباعدة:$myHashRef->{ $keys1[$i] }->{ $keys3{$k} }.

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

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

• صحيحة وموحدة المسافة البادئة.السافلة.من الواضح.حتى الآن أرى الكثير من التعليمات البرمجية 100% غير قابل للقراءة بسبب كربي المسافة البادئة, وحتى أقل للقراءة عندما نصف كود بادئة مع علامات التبويب من قبل الشخص الذي المحرر تستخدم حرف 4 علامات أخرى من قبل الشخص الذي المحرر استخدام 8 أحرف علامات التبويب.فقط تعيين الدموي محرر للقيام لينة (مثلالفضاء يحتذى) علامات و لا تجعل الآخرين بائسة.

• خطوط فارغة حول منطقيا وحدات منفصلة من التعليمات البرمجية (سواء كتل فقط مجموعات من الخطوط).يمكنك كتابة 10000 خط برنامج جافا في 1000 خطوط جيدة بيرل.الآن لا أشعر بنديكت أرنولد إذا قمت بإضافة 100-200 خطوط فارغة إلى أولئك 1000 لجعل الأمور أكثر قابلية للقراءة.

• تقسيم اوبر طويلة التعبيرات في خطوط متعددة ، تليها...

• الصحيح المحاذاة العمودية.شاهد الفرق بين:

  if ($some_variable > 11 && ($some_other_bigexpression < $another_variable || $my_flag eq "Y") && $this_is_too_bloody_wide == 1 && $ace > my_func() && $another_answer == 42 && $pi == 3) {
  

  و

  if ($some_variable > 11 && ($some_other_bigexpression < $another_variable || 
      $my_flag eq "Y") && $this_is_too_bloody_wide == 1 && $ace > my_func()
      && $another_answer == 42 && $pi == 3) {
  

  و

  if (   $some_variable > 11
      && ($some_other_bigexpression < $another_variable || $my_flag eq "Y")
      && $this_is_too_bloody_wide == 1
      && $ace > my_func()
      && $another_answer == 42
      && $pi == 3) {
  

  وأنا شخصيا أفضل أن إصلاح المحاذاة العمودية خطوة واحدة عن طريق مواءمة LHS و RHS (خاصة للقراءة في حالة طويلة استعلامات SQL ولكن أيضا في كود بيرل نفسها ، سواء طويلة الشرطية مثل هذا فضلا عن العديد من الخطوط من المهام و تجزئة/مجموعة التهيئة):

  if (   $some_variable               >  11
      && ($some_other_bigexpression   <  $another_variable || $my_flag eq "Y")
      && $this_is_too_bloody_wide    ==  1
      && $ace                         >  my_func()
      && $another_answer             ==  42
      && $pi                         ==  3  ) {
  

  كملاحظة جانبية, في بعض الحالات رمز يمكن أن تكون حتى أكثر قابلية للقراءة/للصيانة بسبب عدم وجود مثل هذه طويلة التعبير في المقام الأول.E. g.إذا كانت محتويات if(){} كتلة هو return, ثم القيام متعددة if/unless البيانات لكل منها عودة كتلة قد يكون أفضل.

Answer 6

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

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

سوف يستشهد آخرون باستخدام Perl لمباني قصيرة الشكل مثل _ ، $! إلخ. كلها يتم حلها بسهولة ... لست مهتمًا بجعل بيرل تبدو مثل جافا.

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

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

باختصار: اكتب برامج لتكون صحيحة أولاً ، ثم تأمينها ، ثم الأداء جيدًا .... بمجرد تحقيق هذه الأهداف ، ثم تقلق بشأن جعل من الجيد أن تتجعد بالقرب من النار.

Answer 7

أود أن أقول نماذج التغليف/الكائنات ، التي تنعكس في بنية الدليل لملفات .pm. بالنسبة إلى الدكتوراه ، كتبت الكثير من كود Perl الذي أعيد استخدامه بعد ذلك. كان لمولد مخطط اللاتكس التلقائي.

Answer 8

سأتحدث بعض إيجابي أشياء لجعل بيرل يمكن الحفاظ عليها.

صحيح أنك عادة لا ينبغي أن تصبح ذكية للغاية مع عبارات كثيفة حقًا لوس أنجلوس return !$@;#% وما شابه ذلك ، ولكن كمية جيدة من ذكي باستخدام مشغلي معالجة القوائم ، مثل map و grep ويعود سياق القائمة من أمثال split والمشغلين المماثلون ، من أجل كتابة التعليمات البرمجية بأسلوب وظيفي يمكن أن يقدم مساهمة إيجابية في الصيانة. في آخر صاحب عمل ، كان لدينا أيضًا بعض وظائف التلاعب بالتجزئة التي عملت بطريقة مماثلة (hashmap و hashgrep, ، على الرغم من أننا من الناحية الفنية لم نتغذى إلا على قوائم متساوية). على سبيل المثال:

# Look for all the servers, and return them in a pipe-separated string
# (because we want this for some lame reason or another)
return join '|', 
       sort
       hashmap {$a =~ /^server_/ ? $b : +()} 
       %configuration_hash;

أنظر أيضا ترتيب أعلى بيرل, http://hop.perl.plover.com - يمكن أن يؤدي الاستخدام الجيد للتصوير المائي يجعل المهام المحددة أكثر تماسكًا وقابلة للقراءة ، إذا كان بإمكانك الحفاظ على metaprogramming نفسها من الوصول إلى الطريق.