درک ذن پایتون (zen of python)

Zen of Python مجموعه ای از 19 دستور است که برنامه نویس پایتون را برای طراحی بهتر برنامه ها راهنمایی میکنند. این اصول توسط مهندس نرم افزار تیم پیترز نوشته شده است. او می خواست که Guido van Rossum، خالق پایتون، اصل بیستم را اضافه کند. با این حال، این اتفاق هرگز نیفتاد، بنابراین فقط 19 اصل وجود دارد.

PEP ها (پیشنهادهای ارتقای پایتون) اسنادی هستند که اطلاعات مهمی را به جامعه پایتون ارائه می دهند یا ویژگی جدیدی را برای پایتون توصیف می کنند. 19 اصل ذن پایتون در PEP-20، گنجانده شده است و به عنوان بخش مهمی از فرهنگ زبان پایتون، هر برنامه نویسی باید از آن آگاه باشد.

برای دیدن ذن پایتون باید از ماژول this استفاده کنید:

>>> import this
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

دوره پیشنهادی: دوره آموزش رایگان پایتون

 #  آشنایی با اصول ذن پایتون

با وجود اینکه اصول Zen of Python توسط یک مهندس نرم افزار تهیه شده است، اما به هر زبانی نوشته شده اند، جز زبان فنی. بنابراین ممکن است واقعاً نیاز داشته باشیم که این اصول زیبا را بیشتر توضیح دهیم.

 1  زیبا بهتر از زشت است

کد زیبا بهتر از کد زشت است. اگر دو قطعه کد هر دو کار می کنند، اما یکی ساده و به راحتی قابل خواندن است، در حالی که دیگری نامرتب و درک آن دشوار است، قطعاً اولی برنده است. پایتون به دلیل سادگی، خوانایی و ظرافت خود شناخته شده است. اگر می خواهید کد شما پایتونیک به نظر برسد، به سازگاری و سادگی آن توجه کنید.

 2  صریح بهتر از ضمنی است

کد باید برای کسی که چیزی از برنامه شما نمی داند قابل درک باشد. هیچ دانش قبلی نباید مورد نیاز باشد. کدتان را آنقدر صریح بنویسید که تمام عملکرد آن مشخص باشد.

 3  ساده بهتر از پیچیده است

اگر مشکل ساده ای دارید که با یک راه حل ساده قابل حل است، آن را دنبال کنید. اگر مشکل پیچیده ای دارید، آن را به چندین مشکل ساده تقسیم کنید که با یک راه حل ساده قابل حل است. کد خود را بیش از حد پیچیده نکنید تا خفن به نظر برسید. این در پایتون قدردانی نمی شود.

مقاله پیشنهادی: تفاوت لیست و آرایه پایتون چیست؟

 4  پیچیده بهتر از بغرنج است

وقتی مشکل شما نیاز به یک راه حل پیچیده دارد، باز هم نباید خیلی پیچیده باشد. کدهای پیچیده باعث سردرگمی برنامه نویسان می شود و زمان و تلاش زیادی را می گیرد. حتی زمانی که با مشکلات پیچیده کار می کنید، کد خود را تا حد امکان ساده و خوانا نگه دارید.

 5  مستقیم و صاف بهتر از تودرتو است

آیا از طرفداران بزرگ سازماندهی چیزها در دسته ها و زیرمجموعه ها هستید؟ خب، وقتی نوبت به سازماندهی کد شما می رسد، ساختارهای تودرتو اصلا پرطرفدار نیستند. به ساختار کد مسطح با حداقل تودرتو بچسبید. این برای خوانایی کد بسیار مهم است – و همانطور که می دانید، ما به خوانایی در پایتون اهمیت زیادی می دهیم.

 6  پراکنده بهتر از متراکم است

سعی نکنید با فشرده کردن تعداد زیادی از عملکردها در یک خط کد، کسی را تحت تأثیر قرار دهید. ممکن است برای غیر برنامه نویسان جالب به نظر برسد، اما در واقع، برنامه نویسان همکار شما را که برای درک کد شما به زمان بیشتری نیاز دارند، گیج می کند. معمولاً ترجیح داده می شود چندین خط کد با قابلیت دنبال کردن آسان نسبت به یک خط متراکم داشته باشید.

 7  خوانایی مهم است

اغلب، برنامه نویسان سعی می کنند با مخفف کردن نام متغیرها و توابع یا پرش از نظرات (یا بیان نظرات بیش از حد مختصر) در زمان صرفه جویی کنند. به یاد داشته باشید: شما ممکن است فقط یک بار کد بنویسید، اما افراد احتمالاً باید چندین بار آن را بخوانند. اگر واقعاً می‌خواهید در زمان صرفه‌جویی کنید، کد خود را با استفاده از نام متغیرها و توابع قابل فهم، اسناد گسترده و تورفتگی مناسب قابل خواندن کنید.

ویدیو پیشنهادی: ویدیو آموزش آرایه در پایتون

 8  موارد ویژه آنقدر مهم نیستند که بخواهید قوانین را نادیده بگیرید

در پایتون، روش‌های خوبی(best practice) وجود دارد که کد شما را برای برنامه‌نویسان خواناتر می‌کند. به جای اینکه از روش های ابداعی خودتان استفاده کنید از روش های پیشنهادی پایتون استفاده کنید. این قانون به ویژه زمانی مهم است که ماژول ها یا کتابخانه هایی را برای استفاده دیگران ایجاد می کنید.

 9  هر چند که عملی بودن، خلوص را مغلوب میکند

با این حال، هر قانون ممکن است استثنایی داشته باشد. اگر حل یک مشکل "به روش شما" عملی تر است و کد را خواناتر و آسانتر میکند میتوانید روش های پیشنهادی پایتون(best practice) را نادیده بگیرید. درک تفاوت بین این اصل و اصل بالا برای مبتدیان برنامه نویسی می تواند چالش برانگیز باشد، اما با تجربه آسان تر می شود.

 10  خطاها هرگز نباید در سکوت رها شوند

اگر خطایی وجود داشته باشد و برنامه شما None یا فقط یک کد خطا را برگرداند، شما یک خطای خاموش دارید. این خوب نیست. خاموش کردن خطاها در نهایت منجر به اشکالاتی می شود که از بین بردن آنها سخت تر است (زیرا ردیابی علت اصلی دشوارتر است). از کار افتادن یک برنامه بهتر از خاموش کردن خطا و ادامه اجرای آن است.

 11  مگر اینکه صراحتا ساکت شده باشند

در برخی موارد، ممکن است بخواهید خطاهایی را که برنامه شما ایجاد کند نادیده بگیرید. پس بهترین کار این است که این خطا را به صراحت در کد خود غیرفعال کنید.

 12  در زمان ابهام، از حدس زدن دوری کنید

اگر کد شما کار نمی کند، کورکورانه راه حل های مختلف را امتحان نکنید. ممکن است به جای حل کردن مشکل، آن را پنهان کنید. در عوض، تفکر انتقادی را برای درک مشکل و سپس یافتن راه حل مناسب به کار ببرید.

مقاله پیشنهادی: 9 مهارتی که هر برنامه نویس پایتون باید داشته باشد

 13  برای انجام هر کاری، فقط باید یک راه حل آشکار وجود داشته باشد

وقتی یک مشکل را بتوان به چند روش مختلف حل کرد، انعطاف پذیری زیادی در انتخاب راه حل وجود دارد. اما انعطاف پذیری باعث ایجاد پیچیدگی میشود، زیرا باید با تمام راه حل های ممکن آشنا باشید.

در دنیای پایتون میخواهیم همه چیز ساده باشد و یک مثال خوب از آن در درون این اصل خاص پنهان شده است. در این اصل به عملگر postfix (خط تیره) بعد از "one" و عملگر پیشوند قبل از "obvious" توجه کنید:

There should be one-- and preferably only one --obvious way to do it.

برنامه نویسان جدید اغلب در مورد زمان استفاده از عملگرهای پسوند یا پیشوند سردرگم هستند. پایتون این مشکل را با پشتیبانی نکردن از این دو حل می کند.

 14  اگرچه ممکن است این روش در ابتدا واضح و آشکار نباشد مگر اینکه شما هلندی باشید

این اصل به خالق پایتون Guido van Rossum اشاره دارد که هلندی است. بدیهی است که یادآوری و درک هر قانون در پایتون برای او آسان تر از هر کس دیگری خواهد بود.

 15  حالا بهتر از هرگز است

این اصل حداقل دو تفسیر متفاوت دارد. برخی از مردم فکر می کنند که این به حلقه های بی نهایت و بی پایانی اشاره دارد که واضح است که باید در کد خود از آنها اجتناب کنید. تفسیر احتمالی دیگر این است که شما فقط باید از تعلل در پروژه های برنامه نویسی خود اجتناب کنید. من فکر می کنم اگر هر دوی این تفسیرها را بپذیریم ضرری نخواهد داشت.

 16  اگرچه هرگز بهتر از همین حالا است

این اصل ایده های قبلی را توضیح می دهد. اگر آن را مستقیماً روی کد خود اعمال کنیم، می توانیم بگوییم که بهتر است منتظر بمانیم تا یک برنامه تمام شود تا اینکه زودتر آن را خاتمه دهیم و نتایج نادرست دریافت کنیم. اگر به طور کلی در مورد پروژه های برنامه نویسی صحبت می کنیم، می توانیم این اصل را به عنوان فراخوانی برای قرار دادن کمی فکر و برنامه ریزی در پروژه به جای پرش فوری به آن تعبیر کنیم.

 17  اگر تشریح پیاده سازی سخت باشد، پس ایده بدی است

اگر توضیح اجرای خود برای همکارانتان برای شما چالش برانگیز است، احتمالاً با کد بد نوشته شده است. به احتمال زیاد، شما آن را بیش از حد پیچیده کرده اید و تعدادی از اصول بالا را زیر پا گذاشته اید. سعی کنید راه حل خود را تا زمانی که در توضیح آن برای برنامه نویسان دیگر احساس راحتی کنید، ساده کنید.

 18  اگر تشریح پیاده سازی آسان باشد، ممکن ایده خوبی باشد

اگر بتوانید به راحتی اجرای خود را برای همکاران خود توضیح دهید، ممکن است خوب باشد. هنوز هم ممکن است اشتباه باشد، اما شما از نظر خوانایی کد و سادگی در مسیر درستی هستید.

 19  فضای نام ها ایده بی نظیری هستند، بیایید بیشتر از آنها استفاده کنیم

در پایتون، می‌توانید فضاهای نام ایزوله یا مجموعه‌ای از نام‌ها را داشته باشید که به هر شیئی در برنامه شما اجازه می‌دهد یک نام منحصر به فرد داشته باشد. فضاهای نام سیستمی را ایجاد می‌کنند که در آن نام‌های یکی از ماژول‌های شما با نام‌های موجود در دیگری تضاد ندارند. این باعث می شود آنها بسیار مفید باشند.