نوشته های میلاد محمودی

چطور کدت رو تمیز کنی؟ تکنیک‌های رفیکتورینگ از کتاب مارتین فاولر فصل ششم

میلاد محمودی — Tue, 29 Jul 2025 00:05:21 +0330

اگه برنامه‌نویس باشی، حتماً یه روزایی به کدت نگاه کردی و گفتی: «این دیگه چیه؟ چرا این‌جوری نوشتم؟» اینجا تکنیک‌های رفیکتورینگ به دادت می‌رسن! کتاب "Refactoring: Improving the Design of Existing Code" مارتین فاولر مثل یه راهنمای جادوییه که بهت نشون میده چطور کدت رو مرتب و خوانا کنی، بدون اینکه خرابش کنی. فصل ششم این کتاب یه سری تکنیک پایه‌ای و باحال معرفی می‌کنه که هر برنامه‌نویسی باید تو جعبه ابزارش داشته باشه. بریم ببینیم این تکنیک‌ها چی‌ان.با یه توضیح مختصر و مثال‌های ساده پایتونی.قبل از شروع، سه تا چیز رو باید برای هر تکنیک در نظر بگیریم:انگیزه(Motivation): چرا باید این تکنیک رو استفاده کنیم؟ چه مشکلی رو حل می‌کنه؟مکانیزم(Mechanics): قدم‌به‌قدم چطور باید این کار رو انجام بدیم؟مثال(Example): یه نمونه عملی که نشون بده قبل و بعدش چه فرقی می‌کنه.حالا بریم سراغ تکنیک‌های رفیکتورینگ.۱. استخراج تابع(Extract Function)انگیزه:وقتی یه تیکه کد داری که یه کار مشخص(مثل محاسبه یا چاپ چیزی) انجام میده، بهتره بندازیش تو یه تابع جدا با یه اسم معنی‌دار. این‌جوری کدت خواناتر میشه، می‌تونی تابع رو جای دیگه استفاده کنی، و تست کردنش هم راحت‌تره.مکانیزم:تیکه کدی رو پیدا کن که یه کار مشخص انجام میده.یه تابع جدید با اسم خوب بساز.متغیرهای مورد نیاز رو به‌عنوان پارامتر به تابع بده.کد اصلی رو با فراخوانی تابع جایگزین کن.تست کن که همه‌چیز درست کار می‌کنه.مثال(پایتون):استخراج تابع(Extract Function)۲. درون‌خط کردن تابع(Inline Function)انگیزه:اگه یه تابع خیلی ساده‌ست(مثلاً یه خط کد) و اسمش چیزی به فهم کد اضافه نمی‌کنه، می‌تونی بدنه‌شو بندازی تو جایی که صداش کردی و خود تابع رو حذف کنی. این کار کدت رو جمع‌وجورتر می‌کنه، ولی باید مطمئن شی که خوانایی کدت بهم نمی‌ریزه.مکانیزم:همه جاهایی که تابع صدا شده رو پیدا کن.بدنه تابع رو جایگزین فراخوانی‌ها کن.تابع رو حذف کن و تست کن.مثال(پایتون):درون‌خط کردن تابع(Inline Function)۳. استخراج متغیر(Extract Variable)انگیزه:وقتی یه عبارت پیچیده تو کدت داری(مثل یه فرمول بزرگ)، بهتره اونو تو یه متغیر با اسم معنی‌دار بندازی. این کار باعث میشه کدت واضح‌تر بشه، دیباگ کردن راحت‌تره، و اگه بخوای بعداً چیزی بهش اضافه کنی، دستت بازه.مکانیزم:عبارت پیچیده رو به یه متغیر بده.عبارت رو تو کد با متغیر جایگزین کن.تست کن که چیزی خراب نشده.مثال(پایتون):استخراج متغیر(Extract Variable)۴. درون‌خط کردن متغیر(Inline Variable)انگیزه:اگه یه متغیر فقط یه بار مقدار گرفته و مستقیم تو یه عبارت استفاده شده، می‌تونی حذفش کنی و مقدارشو مستقیم بندازی تو عبارت. این کار کدت رو ساده‌تر می‌کنه، مخصوصاً وقتی متغیر اضافی فقط داره جا می‌گیره.مکانیزم:اولین جایی که متغیر استفاده شده رو پیدا کن.مقدار متغیر رو مستقیم تو عبارت بذار.متغیر رو حذف کن و تست کن.مثال(پایتون):درون‌خط کردن متغیر(Inline Variable)۵. تغییر اعلام تابع(Change Function Declaration)انگیزه:اگه اسم یه تابع گنگه یا پارامترهاش با نیازهای پروژه جور درنمیاد، این تکنیک بهت کمک می‌کنه اسم یا پارامترها رو عوض کنی. یه اسم خوب یا پارامترهای درست باعث میشه کدت برای خودت و تیمت قابل فهم‌تر بشه.مکانیزم:برای تغییر اسم، یه تابع جدید با اسم موقت بساز.فراخوانی‌های تابع قدیمی رو به تابع جدید هدایت کن.تابع قدیمی رو حذف کن.برای تغییر پارامتر، تغییرات رو یکی‌یکی اعمال کن و تست کن.مثال(پایتون):تغییر اعلام تابع(Change Function Declaration)۶. کپسوله کردن متغیر(Encapsulate Variable)انگیزه:اگه یه متغیر(مثل یه متغیر global یا تو کلاس) مستقیماً تو کد دستکاری میشه، این تکنیک میگه با توابع getter و setter کنترلش کن. این‌جوری می‌تونی مطمئن شی تغییرات معتبرن، جلوی باگ‌های عجیب رو بگیری، و بعداً منطق اضافی(مثل چک کردن داده) بهش اضافه کنی.مکانیزم:توابع getter و setter برای متغیر بساز.دسترسی‌های مستقیم به متغیر رو با getter/setter جایگزین کن.متغیر رو خصوصی کن(مثلاً با _ تو پایتون).برای داده‌های mutable(مثل لیست)، تو getter کپی برگردون.مثال(پایتون):کپسوله کردن متغیر(Encapsulate Variable)بحثی که پیش میاد اینه که آیا تو پایتون میشه کپسوله‌سازی(Encapsulation) کرد یا نه؟!کپسوله‌سازی تو پایتون یه کم با زبان‌های دیگه مثل جاوا یا سی‌پلاس‌پلاس فرق داره و ممکنه به نظر بیاد که «معنی نمیده» یا حداقل به اون شکل کلاسیک تو پایتون پیاده‌سازی نمی‌شه.تو پایتون، برخلاف زبان‌هایی مثل جاوا که با کلیدواژه‌هایی مثل private یا protected دسترسی به متغیرها و متدها رو سخت‌گیرانه کنترل می‌کنن، فلسفه متفاوتی وجود داره. پایتون خیلی روی «ما همه بزرگسالیم» (We're all consenting adults) تأکید داره، یعنی فرض می‌کنه برنامه‌نویس می‌دونه داره چی کار می‌کنه و نباید بیش از حد محدودش کرد. ولی این به این معنی نیست که کپسوله‌سازی تو پایتون بی‌معنیه! فقط مدلش فرق داره و بیشتر به صورت توافق(convention) پیاده می‌شه تا اجبار.چرا کپسوله‌سازی تو پایتون متفاوته؟عدم وجود private واقعی: تو پایتون، هیچ متغیر یا متدی کاملاً خصوصی نیست. مثلاً:اگه یه متغیر رو با _ شروع کنی(مثل my_var_)، فقط یه توافقه که «این خصوصی‌ست، مستقیم بهش دست نزن». ولی هنوز می‌تونی بهش دسترسی پیدا کنی.اگه از __ (۲تا ) استفاده کنی(مثل my_var__)، پایتون یه چیزی به اسم name mangling انجام میده و اسم متغیر رو عوض می‌کنه(مثلاً به ClassName__my_var)، ولی بازم می‌تونی با یه کم زحمت بهش دسترسی پیدا کنی.فلسفه پایتونیک: پایتون ترجیح میده به جای قفل کردن داده‌ها، روی خوانایی و سادگی تمرکز کنه. اما این باعث نمی‌شه کپسوله‌سازی بی‌فایده باشه.کاربرد واقعی: حتی تو پایتون، کپسوله‌سازی برای کنترل دسترسی، جلوگیری از تغییرات ناخواسته، و اضافه کردن منطق(مثل اعتبارسنجی) به متغیرها خیلی مهمه.درنهایت چرا این تکنیک‌ها رو باید بلد باشیم؟این تکنیک‌های رفیکتورینگ که تو فصل ششم کتاب مارتین فاولر اومده، مثل یه جعبه ابزار حرفه‌ای می‌مونن. کمکت می‌کنن کدت رو تمیز، خوانا و قابل نگهداری کنی.تو پروژه‌های تیمی، این تکنیک‌ها باعث میشن هم‌تیمی‌هات راحت‌تر با کد کار کنن و کمتر گیج بشن. چون هر تغییر کوچیکه و با تست همراهه، خیالت راحته که کدت خراب نمیشه.مارتین فاولر تو کتاب "Refactoring: Improving the Design of Existing Code" همش میگه: «بعد از هر تغییر، حتی اگه یه خط کد عوض کردی، تست رو ران کن!» این حرفش خیلی کلیدیه. فاولر اعتقاد داره که رفیکتورینگ باید با قدم‌های کوچیک و مطمئن باشه، و تست کردن بعد هر تغییر(حتی اگه به نظرت خیلی ساده‌ست) باعث میشه مطمئن شی کدت هنوز درست کار می‌کنه. این کار مثل یه شبکه ایمنیه که نمی‌ذاره باگ‌های عجیب غافلگیرت کنن.تو بلندمدت، این تست‌های مداوم دیباگ رو خیلی راحت‌تر می‌کنن، چون می‌دونی هر تیکه کدت تو چه مرحله‌ای سالمه و اگه چیزی خراب بشه، سریع می‌فهمی از کجا بوده.توی پروژه‌هاتون کدوم‌یک از این تکنیک‌ها رو استفاده کردین؟ یا شاید یه تجربه باحال از رفیکتورینگ دارید که کدتون رو حسابی بهتر کرده؟ تو کامنتا برام بنویسید.

تست نویسی به زبان خیارشور(Gherkin)

میلاد محمودی — Mon, 16 Oct 2023 19:19:49 +0330

تست‌نویسی یک جزء بسیار مهم و بنیادی در مهندسی نرم‌افزار است که اهمیت بسیار زیادی دارد که به منظور ارزیابی و اعتبارسنجی کیفیت و عملکرد یک نرم‌افزار یا سیستم انجام می‌شود. هدف اصلی تست نویسی، تشخیص خطاها، مشکلات و عدم انطباق با نیازمندی‌ها در نرم‌افزار است.در زیر به تعدادی از مفاهیم اساسی در مورد تست نویسی می‌پردازیم:تست کیفیتی (Quality Assurance Testing): این نوع تست به ارزیابی کیفیت کلی نرم‌افزار می‌پردازد. این تست شامل تست‌هایی مانند تست عملکردی، تست عملیاتی، تست امنیتی و ... است.تست اجرایی (Functional Testing): در این نوع تست، عملکرد و ویژگی‌های نرم‌افزار با استفاده از ورودی‌ها و شرایط مختلف ارزیابی می‌شوند تا اطمینان حاصل شود که نرم‌افزار به درستی عمل می‌کند.تست واحد (Unit Testing): در این نوع تست، توابع و واحدهای کوچکتر نرم‌افزار به صورت جداگانه تست می‌شوند. این تست‌ها به تایید درستی عملکرد هر واحد کمک می‌کنند.تست ادغامی (Integration Testing): این تست‌ها بررسی تعامل و ادغام بین مؤلفه‌ها یا واحدهای مختلف نرم‌افزار را انجام می‌دهند تا اطمینان حاصل شود که آنها با یکدیگر به درستی کار می‌کنند.تست عملکردی (Performance Testing): این نوع تست برای اندازه‌گیری کارایی و عملکرد نرم‌افزار تحت بارهای مختلف مانند ترافیک بالا یا بارهای زیاد استفاده می‌شود.تست امنیتی (Security Testing): در این نوع تست، نقاط ضعف امنیتی در نرم‌افزار بررسی می‌شوند تا مشکلات امنیتی شناسایی و رفع شوند.تست نفوذ (Penetration Testing): در این تست‌ها، نرم‌افزار توسط متخصصان امنیتی هک می‌شود تا آسیب‌پذیری‌های امنیتی شناسایی شوند.تست نویسی اساسی‌ترین قسمت از تضمین کیفیت نرم‌افزار است و در فرآیند توسعه به تشخیص زودهنگام خطاها و اشکالات، بهره‌وری تیم‌های توسعه و کاهش هزینه‌های مرتبط با خطاها و مشکلات کمک می‌کند تا از ارائه نرم‌افزارهای پایدار و قابل اطمینان به کاربران اطمینان حاصل شود.و اما خیارشور(Gherkin) که در این محتوا درمورد تست نویسی به زبان Gherkin می‌پردازیم.تست Gherkin نوعی تست مرتبط با توسعه رفتار محور(BDD) است. Gherkin زبانی است برای توصیف رفتار نرم‌افزار که در قالبی قابل خواندن و ساختار یافته توسط انسان استفاده می‌شود. این زبان از کلمات کلیدی مانند "When"، "Given" و "Then" برای تعریف سناریوها و مراحل استفاده می‌کند.در تست Gherkin، سناریوها با جملات ساده انگلیسی نوشته می‌شوند و رفتار مورد انتظار یک سیستم را از دیدگاه کاربر نشان می‌دهند. سپس این سناریوها را می‌توان به عنوان تست برای تأیید اینکه این نرم‌افزار همانطور که در نظر گرفته شده است اجرا خواهد شد یا خیر.ابزارهایی مانند Cucumber یا Behave اغلب سناریوهای Gherkin را تفسیر می‌کنند و اجرای تست‌ها را بر اساس این سناریوها انجام می‌دهند.این زبان همکاری بین اعضاء غیر فنی و توسعه‌دهندگان را بهبود می‌دهد زیرا سناریوها در قالبی قابل درک برای هر دو گروه نوشته می‌شوند.فرض کنید ما در حال توسعه فانکشن جمع دو عدد مثبت هستیم و می‌خواهیم یک سناریوی Gherkin برای تست آن بنویسیم.توجه داشته باشید که سناریوها را باید در فایلی با پسوند feature در پوشه features بنویسید.| Project/ | features/ | steps/ # -- Steps directory *.py # -- Step implementation or use step-library python files. | *.feature | logics/#sum_two_positive_number.feature Feature: Addition Testing in Gherkin This feature is designed to test the addition operation for two positive numbers. Scenario Outline: Adding two positive numbers Given I have entered the Given And i have entered the When I calculate the sum of number_1 and number_2 Then The should be calculated Examples: | number_1 | number_2 | result | | 11 | 11 | 22 |این سناریوی Gherkin مراحلی از جمع دو عدد مثبت را با توجه به اعداد و نتیجه مورد انتظار نشان می‌دهد.تا به اینجا ما فقط سناریو جمع دو عدد مثبت را نوشته‌ایم و برای تست فانکشن نیاز است تا این سناریو را روی فانکشن مورد نظر اجرا کنیم. برای اینکار کافیست پکیج behave را نصب کنید.برای اینکار کافیست بعد از ساختن یک محیط مجازی از دستور زیر استفاده کنید:pip install behaveحال با توجه به سناریو نوشته شده باید stepهای این سناریو را بنویسیم.توجه داشته باشید که stepها را باید در پوشه steps در پوشه features بنویسیم.#sum_two_positive_number.py from behave import given, then, when from behave.runner import Context from logics.sum_number import sum_two_positive_number @given("I have entered the {number_1}") def given_step(context: Context, number_1: str) -> None: context.number_1 = number_1 @given("And i have entered the {number_2}") def given_step(context: Context, number_2: str) -> None: context.number_2 = number_2 @when("I calculate the sum of number_1 and number_2") def when_imp(context: Context) -> None: context.sum = sum_two_positive_number( int(context.number_1), int(context.number_2) ) @then("The {result} should be calculated") def then_step(context: Context, result: str) -> None: assert context.sum == int(result)حال با اجرای دستور زیر می‌توانید نتیجه سناریو را مشاهده کنید.bahave features/sum_two_positive_number.featuresدرصورتی که نتیجه تست با نتیجه سناریو نوشته شده مطابقت نداشته باشد، خطا مورد نظر به شما نشان داده خواهد شد.چند نکته درمورد تست Gherkin:زمانی که از Scenario Outline استفاده می‌شود به این نکته توجه داشته باشید که حتما باید از Examples استفاده شود.تنها در صورتی می‌توان از Examples استفاده نکرد که بجای Scenario Outline از Scenario استفاده شده باشد.اگر بیش از یک مقدار برای یک متغیر وجود داشته باشد می‌توان از Examples استفاده کرد; بدین گونه که هر متغیر می‌تواند چندین مقدار داشته باشد.Examples: | number_1 | number_2 | result | | 11 | 11 | 22 | | 2 | 19 | 21 | | 1 | 1 | 2 |تمام مقادیر از جنس استرینگ می‌باشند.اگر مقدار یک متغیر وارد نشده باشد، استرینگ خالی("") در نظر گرفته خواهد شد.در صورتی که تست شما در تمامی سناریوها نیاز به متغیرهای ثابتی باشد، می‌توان از یک Given برای دریافت مقادیر استفاده کرد.بدین صورت که یک تست با توجه به یک یا چند مقدار ثابت، سناریوهای مختلفی داشته باشد; باید برای تمامی سناریوها از یک Given ثابت استفاده شود، در نتیجه فایل استپ این تست نیز یک Given دارد و برای بدست آوردن و استفاده از مقادیر باید روی جدول مقادیر حلقه زده و آنها را در متغیر مناسب در Context قرار داد.@given("Given title") def given_step(context: Context) -> None: for row in context.table: context.number_1 = row.get("number_1")در ادامه برای دسترسی به متغیر number_1 در Whenها از context.number_1 استفاده می‌شود.اینها توضیحات مختصری از تست‌نویسی، مخصوصا تست‌نویسی به زبان Gherkin بود تا با این زبان آشنا شوید. شما می‌توانید با مراجعه به داکیومنت Gherkin روش‌های دیگری از پیاده‌سازی سناریوهای این زبان را یاد گرفته و بیشتر با این زبان جذاب آشنا شوید.

نقش PEP 8 در برنامه‌نویسی پایتون

میلاد محمودی — Tue, 13 Sep 2022 22:51:20 +0430

PEP 8 style guideبه نظرم امروزه قبل از شروع هر کاری نیازه تا ما با اصول و قاعده اون کار آشنا باشیم. آشنایی و انجام اصول و استاندارهای هر کاری می‌تونه کمک زیادی به ما کنه تا هم کارمون رو به بهترین نحو انجام بدیم و هم کاری رو انجام داده باشیم تا هر شخصی در هر جا با دیدن کارمون متوجه عملکردمون بشه.تو دنیای برنامه نویسی هم همینطوره، شما فارغ از اینکه با چه زبان برنامه‌نویسی‌ای کار می‌کنین باید به این اصول و استانداردها برای کدنویسی آشنا باشید تا کدی در سطح جهانی بنویسید.این کار، هم به پیشرفت شغلی شما کمک می‌کنه هم به شخص دیگه‌ای که به کدتون نگاه می‌کنه یا حتی بجای شما و یا کنار شما مشغول بکار می‌شه، بتونه درک درستی از فرآیند کدنویسی داشته باشه.درنتیجه رعایت اصول کدنویسی و همینطور کدنویسی تمیز(clean code) لازمه هر برنامه‌نویسیه که می‌خواد تو این اکوسیستم فعالیت کنه.تو این نوشته می‌خوایم راجع به شیوه‌نامه نگارشی به نام PEP تو پایتون رو باهم مرور کنیم.PEP مخفف عبارت Python Enhancement Proposal به معنیه پیشنهادی برای بهبود پایتونه که یک سری افراد برای رسیدن به یک استاندارد جهانی و کدهای تمیز و خوانا، شیوه و نحوه نگارشی رو تعیین کردن.هر PEP به همراه خودش یک شماره رو به عنوان نام دارد.به نظرم دو تا از مهم‌ترین و کاربردی‌ترین PEPهای پایتون PEP 8 و PEP 20 است که تو این مقاله به PEP 8 می‌پردازیم.بررسی PEP 8:PEP 8 توسط خالق پایتون Guido van Rossum تو سال 2001 الی 2013 نوشته شده و در حال استفاده است.این داکیومنت قوانین کدگذاری کد پایتون رو ارائه می‌ده. یکی از دیدگاه‌هایی که Guido van Rossum داره اینه که، کد خیلی بیشتر از اینکه نوشته بشه خونده می‌شه.در نتجه دستورالعمل‌هایی که تو PEP 8 ارائه شده، به بهبود خوانایی و هماهنگی کد در سطح گسترده، در نظر گرفته شده.نکته مهمی که PEP 8 بهش اشاره می‌کنه اینه که سازگاری کدها مهمه و میگه تا جایی که می‌شه باید از این شیوه‌نامه پیروی کرد.نکته‌ای که هست اینه که تو بعضی از مواقع نمی‌شه از این قواعد پیروی کرد؛ برای همین، تو این مواقع راه‌حلی که داره به ما پیشنهاد می‌شه اینه که بیایم کدهای دیگران رو ببینیم که تو این مواقع چیکار کردن و یا اینکه اون چیزی رو که فکر می‌کنیم بهتره رو انجام بدیم و نکته مهم‌تری که بهش اشاره داره اینه که از پسیدن دریغ نکنیم.پرسیدن می‌تونه سرچ‌کردن هم باشه، پس سرچ‌کرن یادمون نره.مواردی که PEP 8 به اون اشاره می‌کنه:برای یادگرفتن کامل PEP می‌تونید به داکیومنت PEP سر بزنید ولی خوندن این نوشته هم خالی از لطف نیست.تب یا اسپیس؟ مسئله این است:برای تورفتگی ترجیحا از اسپیس استفاده بشه و تب‌ها صرفا باید زمانی استفاده بشه که تو رفتگی‌هایی با استفاده از تب‌ها داشته باشیم.پایتون این اجازه رو به ما نمی‌ده تا از ترکیب تب و اسپیس استفاده کنیم.برای تو رفتگی از 4 تا اسپیس استفاده کنین.حداکثر طول خط:در PEP 8 حداکثر طول هر خط به 79 کاراکتر محدود شده و برای فرمت تکست‌ها و یا داک استرینگ‌ها حداکثر 72 کاراکتر است.قراردادهای نام‌گذاری:کلاس ها معمولاً باید با استفاده از قرارداد PascalCase نوشته بشن؛ طوری که حروف اول کلمات با حرف بزرگ و بقیه حروف با حرف کوچک و بدون استفاده از فاصله یا underscore.# Correct: class MyClass: pass # Wrong: class my_Class: passماژول‌ها، تابع‌ها و متغیرها باید با توجه به قرارداد snake_case بصورت حروف کوچک و بین هر کلمه با underscore برای جداسازی نوشته بشن.# Correct: import module_name def function_name(): pass full_name = 'Milad Mahmoodi' # Wrong: import Modulename def FunctionName(): pass FullName = 'Milad Mahmoodi'نام‌گذاری اکسپشن‌ها هم مثل کلاس‌ها بصورت PascalCase است.# Correct: try: pass except ValueError: pass # Wrong: try: pass except valueError: passثابت‌ها(Constants) کاملا با حروف بزرگ بصورت CAP_WORD نوشته و با استفاده از underscore از هم جدا می‌شن.# Correct: PI = 3.14 GRAVITY = 9.8 GRAVITY_ACCEL = 9.8 # Wrong: pi = 3.14 Gravity = 9.8 GRAVITYACCEL = 9.8پکیج‌ها باید با حروف کوچیک باشن و نمی‌تونیم از underscore برای جداسازی کلمات استفاده کنیم.# Correct: pandas matplotlib # Wrong: Pandas DateTimeفضای خالی(فاصله) در دستورات و عبارات:همونطور که تو مثال‌های قبل دیدید تو زمان تعریف متغیرها، فانکشن‌ها و ... از فاصله استفاده شده.برای مثال:full_name = 'Milad Mahmoodi' PI = 3.14 a = 2 + 1اینجا ما برای تعریف متغیر و ثابت‌ها، قبل و بعد از عملگر انتساب و تو خط آخر هم برای عملگر انتساب و هم برای عملگر جمع نیز یک فاصله گذاشتیم.بعضی از مواقع نباید تو کدنویسی‌مون از فاصله استفاده کنیم؛ در ادامه چند مورد از نبایدها رو نام می‌بریم و با نحوه درستش مقایسه می‌کنیم.بعد از پرانتز، براکت‌ها و بریس‌ها:# Correct: spam(ham[1], {eggs: 2}) # Wrong: spam( ham[ 1 ], { eggs: 2 } ) #...به فاصله بین پرانتزها، براکت‌هاو بریس‌ها دقت کنینبین آخرین کاما و آخرین پرانتز:# Correct: foo = (0,) # Wrong: bar = (0, ) #...به فاصله بین کاما و پرانتز بسته دقت کنینقبل از کاما، سمیکولون یا کولون:# Correct: if x == 4: print(x, y); x, y = y, x # Wrong: if x == 4: print(x , y); x, y = y, xاسلایس‌بندی لیست‌ها:# Correct: ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:] # Wrong: ham[1: 9], ham[1 :9], ham[1:9 :3]قبل از پرانتز باز که لیست آرگومان تابع رو فراخوانی می‌کنه:# Correct: spam(1) # Wrong: spam (1)قبل از براکت باز که شروع به اسلایس‌بندی یا ایندکس‌گذاری می‌کنه:# Correct: dct['key'] = lst[index] # Wrong: dct ['key'] = lst [index]بیشتر از یک فاصله دور عملگرها برای ترازبندی آن‌ها با همدیگه:# Correct: x = 1 y = 2 long_variable = 3 # Wrong: x = 1 y = 2 long_variable = 3خطوط خالی:در زمان تعریف کلاس‌‌ها و متدها باید به خط خالی برای آن‌ها توجه کرد:در زمان تعریف کلاس باید دو خط خالی قبل از تعریف و دو خط خالی بعد از تعریف کلاس در نظر بگیرید.برای متدهایی که تو کلاس تعریف می‌شن باید از بالا و پایین یک خط خالی قرار بدید.بد نیست به این توصیه‌ها هم توجه کرد:از دنباله‌دار کردن فضای خالی تو هر نقطه خودداری کنین.همیشه عملگرها رو با یک فاصله تو دو طرف آن احاطه کنین.اگر از عملگرهایی با اولویت‌های متفاوت استفاده می‌کنین، برای دور عملگرهایی با کمترین اولویت، فضای خالی در نظر بگیرید.# Correct: i = i + 1 submitted += 1 x = x*2 - 1 hypot2 = x*x + y*y c = (a+b) * (a-b) # Wrong: i=i+1 submitted +=1 x = x * 2 - 1 hypot2 = x * x + y * y c = (a + b) * (a - b)طرح بندی کد(Code Lay-out):تورفتگی:خط‌هایی که ادامه‌دار هستن و یا مثل تابع‌هایی که آرگومان دارن باید بصورت عمودی با استفاده از خط ضمنی پایتون که در داخل پرانتز، براکت و بریس‌ها به هم متصل می‌شن، ترازبندی بشن و یا با استفاده از یک hanging indent، تراز بشن.برای تو رفتگی از 4 تا اسپیس استفاده کنین.ترازبندی hanging indent: یک سبک type-setting است که تو اون پرانتز باز یه عبارت، آخرین کاراکتر بدون فاصله خط است و خطوط بعدی تا پرانتز بسته تورفتگی داره.# Aligned with opening delimiter. foo = long_function_name(var_one, var_two, var_three, var_four) # Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest. def long_function_name( var_one, var_two, var_three, var_four): print(var_one) # Hanging indents should add a level. foo = long_function_name( var_one, var_two, var_three, var_four) # Wrong: # Arguments on first line forbidden when not using vertical alignment. foo = long_function_name(var_one, var_two, var_three, var_four) # Further indentation required as indentation is not distinguishable. def long_function_name( var_one, var_two, var_three, var_four): print(var_one)پرانتز، براکت و بریس بسته در ساختارهای چندخطی ممکنه زیر اولین کاراکتر بدون فضا خالی(non-whitespace) آخرین خط لیست قرار بگیره:my_list = [ 1, 2, 3, 4, 5, 6, ] result = some_function_that_takes_arguments( 'a', 'b', 'c', 'd', 'e', 'f', )یا ممکنه زیر اولین کاراکتر خطی که ساختار چند خطی رو شروع می‌کنه، ردیف بشه:my_list = [ 1, 2, 3, 4, 5, 6, ] result = some_function_that_takes_arguments( 'a', 'b', 'c', 'd', 'e', 'f', )تورفتگی در زمان استفاده از عملگرها:به کد پایین توجه کنین!# Wrong: # operators sit far away from their operands income = (gross_wages + taxable_interest + (dividends - qualified_dividends) - ira_deduction - student_loan_interest) # Correct: # easy to match operators with operands income = (gross_wages + taxable_interest + (dividends - qualified_dividends) - ira_deduction - student_loan_interest)در کد بالا به عملگرهای بعد از متغیر‌ها توجه کنین! تو حالت اول بعد از متغیر‌ها از عملگرها استفاده شده، که تو این حالت باید به دنبال این باشیم که ببینیم چه متغیری از چه عملگری استفاده کرده ولی تو روش دوم این مشل حل شده و ما با یک نگاه ساده متوجه می‌شیم که چه متغیری از چه عملگری استفاده کرده.زمان استفاده از کاماهای دنباله‌دار:اکثرا وقتی که از سیستم کنترل ورژن استفاده می‌شه کاماهای اضافی انتهایی مفیدن؛ انتظار می‌ره لیست مقادیر، آرگومان‌ها یا ورودی‌ها(اینپوت‌ها) تو طول پروژه توسعه داده بشن؛ درنتیجه ما با این الگو که هر مقدار(متغیر‌ها، آرگومان‌ها، ورودی‌ها) رو به تنهایی روی یک خط قرار می‌دهم و همیشه یک کاما اضافی رو تو آخر خط قرار می‌دیم و پرانتز، براکت یا بریس بسته رو تو خط بعدی وارد می‌کنیم.# Correct: FILES = [ 'setup.cfg', 'tox.ini', ] initialize(FILES, error=True, ) # Wrong: FILES = ['setup.cfg', 'tox.ini',] initialize(FILES, error=True,)کامنت ها:بدتر از ننوشتن کامنت، نوشتن کامنتیه که با کد همخونی نداره. درنتیجه فکری به حال آپدیت کردن کامنت‌هاتون بکنین.کامنت‌ها باید جمله‌های کاملی باشن. کلمه اول باید با حروف بزرگ نوشته بشن، مگه اینکه علامتی(شناسه) باشه که باید خود علامت رو نوشت(هرگز حروف علامت‌ها رو تغییر ندید!).کدنویسان عزیزی که پایتون می‌نویسید، اگه انگلیسی زبان نیستین لطفا کامنت‌های خودتون رو به زبان انگلیسی بنویسید، مگه اینکه 120% مطمئن باشین که این کد هرگز توسط افرادی غیر از شما و هم زباناتون خونده نمی‌شه.ایمپورت کردن:معمولا ایمپورت‌ها رو باید تو خط‌های جداگانه‌ای نوشت.# Correct: import os import sys from subprocess import Popen, PIPE # Wrong: import sys, osایمپورت کردن باید طبق دسته‌بندی زیر انجام بشه:Standard library imports.Related third party imports.Local application/library specific importsدر نهایت باید یک خط خالی بین هر گروه از ایمپورت‌ها قرار بدید.توصیه‌های برنامه‌نویسی:کد باید طوری نوشته بشه که به پیاده‌سازی‌های دیگه پایتون آسیبی وارد نکنه مثل(PyPy, Jython, IronPython ...) مثلا، برای جملاتی مثل a += b یا a = a + b به CPython برای جفت شدن رشته‌ها اعتماد نکنین. این بهینه‌سازی حتی تو CPython هم قابل اعتماد نیست(فقط برای یکسری از نوع‌ها کار می‌کنه).تو بخش‌هایی که عملکرد حساسی دارن از متدjoin().''باید به جای a += b یا a = a + b استفاده بشه. این متد به ما این اطمینان رو می‌ده که الحاق انجام خواهد شد.مقایسه با singletonهایی مانند None همیشه باید با is یا is not انجام بشه و هرگز نباید با عملگرهای مقایسه‌ای انجام بشه. مانند a is b که نشون میده هر دو متغیر از یک شی یکسان هستند:# Correct: a = None if a is None: pass # Wrong: if a == None: passبرای عملیات‌های مقایسه‌ای تو کلاس‌ها بهتره از متد‌های (__eq__, __le__, __ne__, __lt__, __ge__, __gt__) استفاده کنین. که برای راحت‌تر شدن این موضوع ابزاری به نام ()functools.total_ordering ارائه شده است.همیشه بجای دستور انتساب که یک عبارت lambda رو مستقیماً به یک شناسه متصل می‌کنه، از دستور def استفاده کنین:# Correct: def f(x): return 2*x # Wrong: f = lambda x: 2*xروش اول بطور کلی برای ردیابی و نمایش رشته‌ها مفیدتره. استفاده از دستور انتساب، تنها مزیتی رو که یه عبارت لامبدا می‌تونه نسبت به یه فانکشن ارائه بده رو حذف کنه(یعنی اینکه می‌شه اون رو تو یه عبارت بزرگ‌تر جاسازی کرد).از ()startswith.' ' و ()endswith.' ' به جای اسلایس کردن رشته برای چک کردن پیشوند یا پسوند استفاده کرد که تمیزتر و خطا کمتری دارن:# Correct: if foo.startswith('bar'): pass # Wrong: if foo[:3] == 'bar': passبرای مقایسه نوع شی، همیشه باید به جای مقایسه مستقیم، از متد ()isinstance استفاده کرد:# Correct: if isinstance(obj, int): pass # Wrong: if type(obj) is type(1): passبرای دنباله‌ها(رشته‌ها، لیست‌ها و تاپل‌ها) به این نکته توجه کنین که دنباله‌های بدون عضو، نادرست(False) و دنباله‌های دارای عضو، درست(True) هستن:# Correct: seq = list() if not seq: pass if seq: pass # Wrong: if len(seq): pass if not len(seq): passمقادیر بولی(boolean) رو با استفاده از عملگر مقایسه‌ای، مقایسه نکنین:# Correct: if greeting: pass # Wrong: if greeting == True: pass if greeting is True: passاستفاده از else در مواقع‌ای که حلقه‌های for و while نتیجه‌ای ندارن:ls = [1, 2, 3] for item in ls: if ls == 5: pass else: passدر آخر ممنونم از اینکه وقت گذاشتید و نوشته‌ام رو خوندید. سعی کردم تا اونجایی که تونستم اون‌چیزهایی رو که در مورد PEP 8 خوندم رو با شما به اشتراک بذارم.خیلی خوشحال می‌شم نظراتتون رو داشته باشم.