Zen of Python الگوهای طراحی برای نوشتن کد های کارآمد در پایتون

هر زبان برنامه نویسی برنامه ویژگی های خاص خودش را دارد، که باعث می شود از دیگر زبان ها متمایز شود. هر زبان برنامه نویسی، الگوهای طراحی منحصر به فرد و شیوه خاص خود را دارد. دانستن این ویژگی های باعث می شود، که حرقه ای تر شوید و کد های با کارایی بالا بنوسید.

The Zen of Python یک سری دستورالعمل و توصیه هایی هست که به ما کمک می کند، تا کدهای خوانا تر و بهتری در پایتون بنویسیم.

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

The Zen of Python صرفاً توصیه‌ هستند و اجباری برای رعایت آن‌ها وجود ندارد. اما آشنایی با این الگوهای طراحی و در نظر گرفتن آن‌ها در هنگام کدنویسی، می‌تواند به ما کمک کند تا کدهای تمیزتر و کارآمدتری بنویسیم.

اگر در زبان برنامه نویسی پایتون دستور زیر وارد کنید، 19 دستورالعمل را به شما می دهد.

توضیح دستور های Zen of Python

کد زیبا بهتر از زشت هست (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)

اگر کد شما یک ارور داشته باشد و None یا فقط کد خطا را برگرداند شما دارید ارور را به صورت بی صدا رد می کنید. بهتر است که برنامه هنگام برخورد با ارور متوقف شود تا اینکه به صورت بی صدا رد بشود. اگر در مورد خاصی نیاز دارید که ارور را رد کنید به صورت شفاف و صریح اینکار را کنید.

در موقعیت مبهم از حدس زدن خودداری کنید.

(In the face of ambiguity, refuse the temptation to guess)

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

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

اگر چند راه برای حل مسئله هست به دنبال آسان ترین و ساده ترین آن بروید و سعی کنید چیزها را پیچیده نکنید.

 

الان بهتر از هرگز هست اگرچه در بعضی مواقع هرگز بهتر از همین الان هست.

(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)

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