ماه: نوامبر 2018

یک روش خوب یاد گرفتن برنامه نویسی خوب، بررسی ضد الگوها/AntiPatterns است. اساتید، نمونه‌های بدی که می‌بینن رو منتشر می کن تا بقیه ببینن که چه روشی اشتباهه و از روش روش خوب رو درک کنن. این مجموعه نمونه های بد برنامه نویسی رو من مدت‌ها پیش دیدم و همیشه گذاشته بودم در موردشون بنویسم.. که ظاهرا رسید به الان. به قول خودمون «ادب از که آموختی از بی ادبان». این قسمت دوم از یک مجموعه دو قسمتی است.

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

کامنت اضافی هم چیز بدیه! اینجا بحث زیاده. بعضی ها فیگور «کد کامنت است» میان و بعضی ها برای هر خط کد۱۰ خط کامنت می نویسن. بهتره شما منطقی باشین و معتدل. اشکالی اصلی کد رو این ببینین که برای یک نفر حرفه ای، توضیحات دو تا می شه: کامنت و کد! اگر کامنت شما داره کد رو توضیح می ده، احتمالا کامنت خوبی نیست. کامنت باید اشاره به فلسفه کلی اون بخش بکنه یا مرجعش یا توضیحی از طرف برنامه نویس. بعضی ها می گن کامنت ها باید الگوریتم و دلایل رو توضیح بدن نه روش رو. اگر کد شما بدون کامنت، ناخوانا است یعنی کد بدی نوشتین. اگر قراره جلوی متغیر، توضیح بدین محتواش چیه، بهتره اسم متغیر رو به اون محتوا تغییر بدین. بدترین حالت وقتی است که کد با کامنت نخونه. به هرحال بحث زیاده. مواظب باشین که بین نوشتن کد لابلای صدها خط کامنت و ادعای «کد برای برنامه نویس خوب کامنته» جای معقولی بایستین.

عملیات پیچیده رو نباید در if انجام بدین. من اخیرا در این مورد یه تذکر گرفتم و کدم رو اصلاح کردم. بهتره بخش های مختلف رو قبلا حساب کنین و در متغیرهایی با اسم های خوب بنویسین و بعد یک ایف خوانا بنویسین که «اگر فلان و بهمان». تنها استثناء وقتی است که بخواین با && در ایف، جلوی اجرای شدن قسمت دوم در صورت اشتباه بودن قسمت اول رو بگیرین.

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

یک روش خوب یاد گرفتن برنامه نویسی خوب، بررسی ضد الگوها/AntiPatterns است. اساتید، نمونه‌های بدی که می‌بینن رو منتشر می کن تا بقیه ببینن که چه روشی اشتباهه و از روش روش خوب رو درک کنن. این مجموعه نمونه های بد برنامه نویسی رو من مدت‌ها پیش دیدم و همیشه گذاشته بودم در موردشون بنویسم.. که ظاهرا رسید به الان. به قول خودمون «ادب از که آموختی از بی ادبان». این قسمت اول از یک مجموعه دو قسمتی است.

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

زود برگردین! این توصیه «زود برگرد» رو از بچگی شنیدیم و در برنامه نویسی هم خوبه اگر اونو یادمون باشه. اگر در جایی از یک فانکشن مطمئن شدید که وقت برگشت است، برگردید. اینکه یک متغیر ست کنید و آخر فانکشن تصمیم بگیرین با اون بگردین، فقط کار رو پیچیده تر می کنه و خوندن و دیباگ برنامه رو سخت‌تر. حتی اگر بحث پرفرمنس برامون مهم نباشه.

از اعداد جادویی پرهیز کنید! اینجا معلوم نیست ۵ چیکاره است. چرا ۵؟ چرا شش نه؟ اگر پنج رو در متغیری به اسم max_number_of_tries ریخته بودیم هم برنامه واضح تر بود و هم اگر بعدا کسی می خواست بعد از ۶ بار نظرش رو عوض کنه، خیلی راحت پیدا می کرد کجا باید چیکار کنه. روی پرفرمنس هم هیچ تاثیری نداشت.

یک کلاس بزرگ برای همه کار. اگر می تونین کارهای داخل یک کلاس رو طبقه بندی کنین، بهتره کلاس رو به اون طبقه‌ها بشکنین. گاهی آدم ها برای حل یک مساله واقعا بزرگ کلا یک کلاس بزرگ تعریف می کنن و کل توابع و متغیرها رو می برن اون تو! اینکار رو نکنین.