Pylint من الداخل الى الخارج. كيف يفعل ذلك

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

لكن مكسيم مازاييف يعرف مدى أهمية فهم أدواته ، وقد أخبرنا في Moscow Python Conf ++ . باستخدام أمثلة واقعية ، أوضح كيف ساعدت معرفة الجهاز الداخلي لـ Pylint ومكوناته الإضافية على تقليل وقت مراجعة الشفرة ، وتحسين جودة الشفرة ، وتحسين كفاءة التطوير عمومًا. أدناه هو تعليمات فك التشفير.

لماذا نحتاج بيلينت؟

إذا كنت تستخدمه بالفعل ، فقد يطرح السؤال التالي: "لماذا تعرف ما هو داخل Pylint ، كيف يمكن لهذه المعرفة أن تساعد؟"

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

لفترة طويلة ، عملوا بنفس الطريقة تمامًا مع Pylint في معهد Cyan ، مع إضافات بسيطة: لقد غيروا التكوينات ، وقاموا بإزالة القواعد غير الضرورية ، وزادوا الحد الأقصى لطول السلسلة.

لكن في مرحلة ما واجهوا مشكلة ، والتي كان علي أن أتعمق في Pylint واكتشف كيف تعمل. ما هي هذه المشكلة وكيفية حلها ، اقرأ على.


عن المتحدث: مكسيم مازيف (رد فعل عنيف) ، 5 سنوات في التنمية ، ويعمل في CIAN. يتعلم بعمق بيثون ، البرمجة غير المتزامنة والوظيفية.

حول سماوي

يعتقد معظمهم أن CIAN هي وكالة عقارية بها سماسرة وفوجئوا جدًا عندما يكتشفون أنه بدلاً من أصحاب العقارات لدينا مبرمجون.

نحن شركة فنية لا يوجد فيها سماسرة ، لكن هناك الكثير من المبرمجين.

• 1 مليون مستخدم فريد يوميًا.
• أكبر لوحة إعلانات لبيع وتأجير العقارات في موسكو وسانت بطرسبرغ. في عام 2018 ، دخلوا المستوى الفيدرالي وعملوا في جميع أنحاء روسيا.
• ما يقرب من 100 شخص في فريق التطوير ، منهم 30 يكتبون كود بايثون يوميًا.

كل يوم ، مئات الآلاف من سطور الكود الجديد تدخل حيز الإنتاج. متطلبات الكود بسيطة للغاية:

• رمز الجودة لائق.
• تجانس الأسلوبية. يجب على جميع المطورين كتابة تعليمات برمجية مشابهة تقريبًا ، بدون "الخل الخل" في المستودعات.

لتحقيق ذلك ، بالطبع ، تحتاج إلى مراجعة الكود.

مراجعة الكود

تتم مراجعة الكود في CIAN على مرحلتين:

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

مشاكل مراجعة الكود

قد لا يجتذب طلب السحب مراجعة الكود بسبب:

• أخطاء في منطق العمل عندما يكون المطور قد حل مشكلة بطريقة غير فعالة أو غير صحيحة ؛
• قضايا نمط الرمز.

ما يمكن أن يكون قضايا النمط إذا تحقق linter رمز؟

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

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



"رفض مقترحات Cian" ​​- مجموعة من القواعد ، يوجد الآن حوالي 15. كل قاعدة من هذه القواعد هي الأساس لرفض طلب السحب وإرساله للمراجعة.

ما الذي يعوق مراجعة التعليمات البرمجية المنتجة؟

هناك مشكلة واحدة في قواعدنا الداخلية - لا يعرف linter عنها ، وسيكون من الغريب إذا علم - أنها داخلية.

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

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

نود أن نتخلص من هذه المشكلة.

ولكن لا تكتب لنا linter؟

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

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

إذاً كيف نحل المشكلة إذا كنا لا نريد أن نكتب نسختك الخاصة؟

اكتب ملحق Pylint

يمكنك كتابة مكونات إضافية لـ Pylint ، يطلق عليها لعبة الداما. تحت كل قاعدة داخلية ، يمكنك كتابة المدقق الخاص بك ، والذي سوف تحقق من ذلك.

النظر في مثالين من هذه لعبة الداما.

مثال رقم 1

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

المشكلة

كتب المطور وعدًا ، وزفر وذهب مع راحة البال للقيام بالمهمة التالية.


باختصار:

• التعليقات مع الوعود معلقة على مر السنين ولا تتبع ؛
• رمز تناثرت؛
• وقد تراكم الديون الفنية لسنوات.

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

الحل: اكتب مدقق Pylint الخاص بك

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

نحتاج إلى العثور على جميع تعليقات النموذج TODO والتأكد من أن كل واحد منهم لديه رابط لمهمة في جيرا. دعنا نكتب.

ما هو المدقق من حيث Pylint؟ هذه فئة ترث من الفئة الأساسية للمدقق وتنفذ واجهة معينة.

class TodoIssueChecker(BaseChecker): _ _implements_ _ = IRawChecker 

في حالتنا ، هذا هو IRawChecker - المدقق "الخام" يسمى.

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

للمدقق ، تحتاج إلى تحديد قائمة الرسائل التي ستصدرها:

 msgs = { '9999': ('  TODO    ', issue-code-in-todo', ' ')} 

تحتوي الرسالة على:

• الوصف قصير وطويل ؛
• رمز المدقق واسم ذاكري قصير يحدد نوع الرسالة هو.

يحتوي رمز الرسالة على النموذج "C1234" ، والذي:

• تم توحيد الحرف الأول بشكل واضح لأنواع مختلفة من الرسائل: [C] onvention؛ [ث] arning. [E] زبادي ؛ [F] أتال ؛ [ص] efactoring. بفضل الرسالة ، يُظهر التقرير على الفور ما يحدث: تذكير بالاتفاقيات أو المشكلات المميتة التي تحتاج إلى معالجة عاجلة.
• 4 أرقام عشوائية فريدة من نوعها لبيلينت.

هناك حاجة إلى رمز لتعطيل الاختيار إذا أصبح غير ضروري. يمكنك كتابة Pylint: تعطيل ورمز أبجدي رقمي قصير أو اسم ذاكري:

 # Pylint: disable=C9999 # Pylint: disable=issue-code-in-todo 

يوصي مؤلفو Pylint بالتخلي عن الكود الأبجدي الرقمي واستخدام ذاكري ، وهو أكثر بصرية.

الخطوة التالية هي تحديد طريقة تسمى process_module .



الاسم مهم جدا يجب استدعاء الطريقة بهذه الطريقة ، لأن Pylint سوف يطلق عليها بعد ذلك.

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

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

تسجيل المدقق حتى يعرف Pylint عن ذلك. يتم ذلك عن طريق وظيفة التسجيل :

 def register(linter: Pylinter) -> None: linter. register_checker ( TodoIssueChecker(linter) ) 

• مثيل Pylint يأتي في الوظيفة.
• وهو يستدعي طريقة register_checker.
• نمر المدقق إلى الطريقة.

نقطة مهمة: يجب أن تكون وحدة المدقق في PYTHONPATH حتى يتمكن Pylint من استيرادها لاحقًا.

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

 $ cat work. # T0D0:   , -! $ pylint work. --load-plugins todo_checker … 

للاختبار ، قم بتشغيل Pylint ، وقم بتمرير الوحدة النمطية إليه ، واستخدم معلمة plugins الإضافية لتمرير المدقق ، وفي داخل linter ، قم بتشغيل مرحلتين.

المرحلة 1. تهيئة البرنامج المساعد

• يتم استيراد جميع الوحدات مع الإضافات. Pylint لديها لعبة الداما الداخلية والخارجية. انهم جميعا معا ويتم استيرادها.
• نسجل - module.register (النفس) . لكل مدقق ، يتم استدعاء وظيفة التسجيل ، حيث يتم تمرير مثيل Pylint.
• يتم إجراء الاختبارات: من أجل صحة المعلمات ، لوجود الرسائل والخيارات والتقارير بالتنسيق الصحيح.

المرحلة 2. تحليل مجموعة من لعبة الداما

بعد المرحلة الأولى ، تبقى قائمة كاملة بأنواع مختلفة من لعبة الداما:

• مدقق AST.
• المدقق الخام.
• المدقق رمزي.

من القائمة نختار تلك التي تتعلق بواجهة المدقق "الأولية": نحن ننظر إلى أي لعبة الداما تنفذ واجهة IRawChecker ونأخذها لأنفسنا.

لكل مدقق محدد ، اتصل بطريقة checker.process_module (وحدة نمطية) ، وقم بتشغيل التحقق.

النتيجة

قم بتشغيل المدقق في ملف الاختبار مرة أخرى:

 $ cat work. # T0D0:   , -! $ pylint work,  --load-plugins todo_checker : 0,0:   T0D0     (issue-code-in-todo) 

ستظهر رسالة تفيد بوجود تعليق مع TODO وليس هناك رابط للمهمة.

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

مثال رقم 2. الوسيطات الحجج

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

المشكلة

على سبيل المثال ، لدينا وظيفة:

 get_offer_by_cian_id( "sale", rue, 859483, ) 

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

 get_offer_by_cian_id( deal_type="sale", truncate=True, cian_id=859483, ) 

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

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

كلمات عن AST

إن AST أو شجرة بناء الجملة المجردة هي عبارة عن تمثيل شجرة للكود ، حيث يكون الرأس هو المعاملات والأوراق عاملين.

على سبيل المثال ، يتم تحويل استدعاء دالة ، حيث توجد وسيطة موضعية واحدة وسيطات مسماة ، إلى شجرة مجردة:


هناك قمة مع نوع الدعوة ولها:

• سمات وظيفة تسمى فونك.
• قائمة وسيطات موضعية ، حيث توجد عقدة ذات نوع Const وقيمة 112 ؛
• قائمة الحجج المسماة الكلمات الأساسية.

المهمة في هذه الحالة:

• البحث في الوحدة النمطية جميع العقد مع نوع استدعاء (استدعاء وظيفة).
• حساب إجمالي عدد الوسائط التي تأخذها الدالة.
• إذا كان هناك أكثر من وسيطين ، فتأكد من عدم وجود وسيطات موضعية في العقدة.
• إذا كانت هناك وسيطات موضعية ، فقم بعرض تحذير.

 ll( func=Name(name='get_offer'), args=[Const(value=1298880)], keywords=[ … ]))] 

من وجهة نظر Pylint ، المدقق المستندة إلى AST هو فئة ترث من فئة المدقق الأساسي وتنفذ واجهة IAstroidChecker :

 class NonKeywordArgsChecker(BaseChecker): -_ _implements_ _ = IAstroidChecker 

كما في المثال الأول ، يشار إلى وصف المدقق ورمز الرسالة والاسم المختصر في قائمة الرسائل:

 msgs = { '9191': (' ', keyword-only-args', ' ')} 

الخطوة التالية هي تحديد طريقة visit_call :

 def visit_call(self, node: Call) … 

ليس من الضروري أن يسمى ذلك. أهم شيء فيها هو بادئة visit_ ، ثم يأتي اسم قمة الرأس التي تهمنا بحرف صغير.

• يمرر المحلل اللغوي AST من خلال الشجرة ولكل قمة يتطلع إلى معرفة ما إذا كان لدى checker واجهة visit_ <Name> محددة.
• إذا كان الأمر كذلك ، فاتصل بها.
• يمر بشكل متكرر من خلال جميع أطفالها.
• عند مغادرة العقدة ، فإنه يستدعي الأسلوب leave_ <Name>.

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

 def visit_call(self, n): if node.args and len(node.args + node.keywords) > 2: self.add_message( 'keyword-only-args', node=node ) 

نقوم بتسجيل المدقق ، كما في المثال السابق: نقوم بنقل مثيل Pylint ، ندعو register_checker ، نمر المدقق نفسه ونبدأه.

 def register(linter: Pylinter) -> None: linter.register_checker( TodoIssueChecker(linter) ) 

هذا مثال على استدعاء دالة الاختبار حيث توجد 3 وسائط وسيُسمى واحد منها فقط:

 $ cat work. get_offers(1, True, deal_type="sale") $ Pylint work.py --load-plugins non_kwargs_checker … 

هذه وظيفة يُحتمل أن تُدعى بشكل غير صحيح من وجهة نظرنا. إطلاق Pylint.

تتكرر مرحلة تهيئة المكون الإضافي 1 تمامًا ، كما في المثال السابق.

المرحلة 2. وحدة التحليل في AST

يتم تحليل الرمز في شجرة AST. يتم إجراء التحليل بواسطة مكتبة Astroid .

لماذا Astroid ، وليس AST (stdlib)

لا يستخدم Astroid داخليًا وحدة Python AST القياسية ، ولكن يستخدم محلل AST المكتوب من typed_ast ، والذي يتميز بأنه يدعم تلميحات نوع PEP 484. Typed_ast هو فرع من AST ، شوكة تتطور بالتوازي. ومن المثير للاهتمام ، أن هناك نفس الأخطاء الموجودة في AST ، ويتم إصلاحها بشكل متوازٍ.

 from module import Entity def foo(bar): # type: (Entity) -> None return 

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

في مرحلة ما على GitHub ، جاء Guido Van Rossum إلى Astroid وقال: "يا شباب ، لديك Pylint الذي أقسم على مثل هذه الحالات ، ولدينا محلل AST مكتوب يدعم كل هذا. لنكن اصدقاء!

بدأ العمل في الغليان! بعد مرور عامين ، تحول Pylint هذا الربيع إلى محلل AST مكتوب وتوقف عن أداء اليمين مثل هذه الأشياء. لم يعد يتم تمييز عمليات استيراد الأعمدة على أنها غير مستخدمة.

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

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

• مساعدة Astroid تعديل شجرة مجردة وفهم الطبيعة الديناميكية لبيثون.
• تكملة AST بمعلومات مفيدة.

مثال نموذجي هو pylint-django . عند العمل مع نماذج django المعقدة ، يقسم linter غالبًا بسمات غير معروفة. Pylint-django يحل هذه المشكلة.

المرحلة 3. تحليل مجموعة من لعبة الداما

نعود إلى المدقق. لدينا مرة أخرى قائمة من لعبة الداما ، نجد منها تلك التي تطبق واجهة AST checker.

المرحلة 4. تحليل لعبة الداما حسب أنواع العقد

بعد ذلك ، نجد طرقًا لكل مدقق ، ويمكن أن تكون من نوعين:

• visit_ <اسم العقدة>
• lev_ <اسم العقدة>.

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

 _visit_methods = dict( < > : [checker1, checker2 ... checkerN] ) 

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

 _leave_methods = dict( < >: [checker1, checker2 ... checkerN] ) 

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

 $ cat work. get_offers(1, True, deal_type="sale") $ Pylint work.py --load-plugins non_kwargs_checker C: 0, 0:  c >2      (keyword-only-args) 

تم حل المشكلة. الآن ، لا يحتاج مبرمجو مراجعة الكود إلى قراءة وسيطات الوظيفة ؛ حيث سيقوم linter بذلك من أجلهم. لقد وفرنا وقتنا ووقت مراجعة التعليمات البرمجية والمهام تسير بشكل أسرع في الإنتاج.

ولكتابة الاختبارات؟

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

 class TestNonKwArgsChecker(CheckerTestCase): CHECKER_CLASS = NonKeywordArgsChecker 

الخطوة 1. نقوم بإنشاء اختبار AST- العقدة من جزء الكود الذي نتحقق منه.

 node = astroid.extract_node( "get_offers(3, 'magic', 'args')" ) 

الخطوة 2. تحقق من أن المدقق ، الذي يدخل العقدة ، إما يلقي أو لا يلقي الرسالة المقابلة:

 with self.assertAddsMessages(message): self.checker.visit_call(node) 

Tokenchecker

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


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

كيف يعمل Pylint مع TokenChecker:

• وحدة تحت الاختبار رمزية.
• يتم تمرير قائمة ضخمة من الرموز المميزة إلى جميع أجهزة الفحص التي تقوم بتطبيق ITokenChecker وتسمى طريقة process_tokens (الرموز).

لم نعثر على استخدام TokenChecker ، ولكن هناك بعض الأمثلة التي يستخدمها Pylint:

• التدقيق الإملائي . على سبيل المثال ، يمكنك أن تأخذ جميع الرموز المميزة مع كتابة النص وإلقاء نظرة على محو الأمية المعجمية ، والتحقق من الكلمات من قوائم كلمات التوقف ، إلخ.
• تحقق المسافات البادئة والمسافات.
• العمل مع الاوتار . على سبيل المثال ، يمكنك التحقق من أن Python 3 لا يستخدم حرفي Unicode ، أو تحقق من وجود أحرف ASCI فقط في سلسلة البايت.

الاستنتاجات

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

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

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

يمكنك معرفة المزيد عن Pylint وكيفية كتابة لعبة الداما في الوثائق الرسمية ، ولكن فيما يتعلق بكتابة لعبة الداما ، فهي سيئة إلى حد ما. على سبيل المثال ، حول TokenChecker لا يوجد سوى ذكر هناك ، ولكن ليس حول كيفية كتابة المدقق نفسه. يتوفر مزيد من المعلومات في مصادر Pylint على GitHub . يمكنك معرفة ما هي لعبة الداما في الحزمة القياسية والحصول على إلهام لكتابة الخاصة بك.

معرفة التصميم الداخلي Pylint يحفظ ساعات العمل ، ويبسط
الأداء ويحسن الرمز. وفر وقتك ، واكتب رمز جيد و
استخدام لينتر.

سيتم عقد مؤتمر Moscow Python Conf ++ التالي في 5 أبريل 2019 ، ويمكنك بالفعل حجز تذكرة بيرف مبكرًا الآن. من الأفضل جمع أفكارك والتقدم بطلب للحصول على تقرير ، ثم ستكون الزيارة مجانية ، وستكون الكعك اللطيف مكافأة ، بما في ذلك التدريب على إعداد التقرير.

مؤتمرنا عبارة عن منصة للقاء أشخاص متشابهين في التفكير ، ومحركات الصناعة ، للتواصل ومناقشة الأشياء التي يحبها مطورو Python: الخلفية والويب ، وجمع البيانات ومعالجتها ، AI / ML ، والاختبار ، وإنترنت الأشياء. كيف حدث ذلك في الخريف ، انظر إلى تقرير الفيديو على قناة بيثون واشترك في القناة - سننشر قريبًا أفضل التقارير من المؤتمر للوصول المجاني.