خب از شما بعد از خوندن این فصل انتظار میره که دیگه به هیچ عنوان تابع های طولانی و کشنده ننویسین، تابع های تودرتو را فراموش کرده و هرچی تابع دارید هیچ اثر جانبی نداشته باشه . اسم گذاری و تعداد ورودی های تابع هم جزو بازی هست . پس بریم و گوش بسپاریم به این فصل دلنواز :
Small
اولین قانون اینه که توابعت کوچولو باشن، دومین قانون اینه که کوچولوتر از اولی
قدیم میگفتن که طوری باشه که بدون اسکرول کردن صفحه بتونی کل تابع رو ببینی ولی تو این دور و زمونه ، با این مانیتورهای اندازه آدمیزاد ، میشه کل پروژه رو توی یک نمای مانیتور مشاهده کرد . پس اون جمله قدیم رو فاتحه اش رو بخون و تابعات نهایتا ۲۰ خط باشه و هر خط نهایتا ۱۵۰ کارکتر.
Indent
در هر تابع مجازید که حداکثر دوتا ایندنت داشته باشید . پس وقتی دیدید هی دارید میرید تو تر و شرط و حلقه رو به نکاح تابع بدبخت درآوردید باید بگم که وقتشه بشکنیدش به چنتا تابع.
Just one thing
تابع باید یه کار بکنه ولی مثل آدم و بهترین کار. یعنی اگر کسی پرسید تابعت مشغول چه کاریه شروع به داستان سرایی نکنی و نیم ساعت طول بکشه هزاران کار تابع رو توضیح بدی.یادت باشه فقط یه کار مثلا بگی داره دوتا عددو جمع میکنه. به همین سادگی .
حالا شبهه ای که پیش میاد:
یه تابع هست رییس جمهور بعدی آمریکا رو پیشبینی میکنه
یه تابع هم هست دو تا عدد رو جمع میکنه .
الان ینی اینا جفتشون درست ان؟ قاعدتا نه . یه چیزی باید باشه که درستی این یدونه کار رو تعیین کنه. این دوراه نشون میده که تابعت یه کار رو نمیکنه :
One Level of Abstraction per Function
خب یه نکته ی دیگه هم که بصورت مخفی اینجا بیان شد این بود که سطوح انتزاع بدنه ی تابع باید در یک سطح باشن . مثلا اونجا که تابعت داره ممد رو اسم گذاری میکنه نیا چک کن که ممد ژیمناستیک کارم هست یا نه.
Reading Code from Top to Bottom: The Stepdown Rule
وقتی هم که داری توابع رو از بالا به پایین مینویسی باید از تابع با سطح انتزاع بالا (نحوه ی پولدار شدن استیو جابز) شروع کنی و تابع با بالاترین سطح انتزاع (جمع دو عدد) رو بذاری ته ه ته . آدم که از بالا میخونه میاد پایین بفهمه چی به چیه.
Switch Statements
اینجا میخواد یکاری کنه که هر وقت از سووییچ استفاده میکنی عذاب وجدان بگیری . دلایلش ایناس :
دیگه گاهی مجبوریم ازش استفاده کنیم و فقط میشه تا حدی جلوی مشکل ۴ ام رو گرفت. مثلا با پلی مورفیزم و اینترفیس و این کول کاریای شی گرایی بیایم فقط یبار سووییچ رو بنویسیم و جور های مختلف ازش استفاده کنیم .
Use Descriptive Names
به این معناس که اسمش دقیقا کار تابع رو توضیح بده و اصلا هم از طولانی شدنش نترسید (البته شورشم در نیارید) . از اینکه وقت زیادی صرف انتخاب اسم بکنید هم نترسید .
Function Arguments
شاید باورتون نشه ولی تعداد ایده‌آل آرگومان ها صفره . بعد یک ، بعد دو نهایتا سه . واسه بیشتر از سه تا واقعا باید دلیل محکمه پسندی ارايه بدی وگرنه باید بیخیالش بشی.
به عنوان مثال اگر گوش شیطون کر خواستی بیشتر از سه تا آرگومان بدی میتونی ورودی‌هارو یه آبجکت کنی و به تابعت پاس بدی یا اگر همشون یه جنسن به صورت آرایه بپاس .
نکته دیگه اینکه ازین ارگومان های فلگ طور نداشته باش . مثلا اگ تورو فرستادی تابع یه کار میکنه اگ فالس فرستادی یه حرکت دیگه. این کار کدتو نجس میکنه . کار خوب اینه که واس هر کدوم ازین کارات یه تابع داشته باشی.
Side effects
اگر یادت مونده باشه تابع باید فقط یه کارو انجام بده . پس عوارض جانبی یه دروغ بزرگه. تابع باید مثل یه پارچه آقا کار خودشو انجام بده ، آسه بره آسه بیاد به کسی هم کاری نداشته باشه. به بقیه چیزا دست نزن !
Command query sepration
تابع یا باید یه کاریو انجام بده واست یا یه جوابی بهت بده . دوتاش همزمان باشه توی کد ابهام ایجاد میکنه. مثلا یه تابع داریم که چک میکنه اگر یوزر نیم وجود نداشت ، بسازش و به عموباب تغیرش بده.
یه بدبختی داره کدتو میخونه و میرسه به این خط :
If(Set(“username”,”uncleBob”))
خب حالا طرف چه فکری راجع بهش میکنه:
اینجا مشکل هم انتخاب اسم تابعس هم همون داستان همیشگی که تابع داره دوتا کار میکنه . اینطوری مشکل رو حل میکنیم :
If(attributeExist(“username”))
setAtrribute(“username”,”uncleBob”)
prefer exception to return error code
جای اینکه شرطهای پی در پی بذاری و به ازای هر اتفاق نا خوشایندی در تابعت یه اروری رو بالابیاری (ایهام تمیز) مثل آدم بیا از try/catch استفاده کن.
Don’t repeat your self
مادر همه مشکلات توی برنامه‌نویسی تکرار (کپی پیست) ه. یه کار رو میخوای جاهای مختلف پروژه انجام بدی و چون حوصله اینو نداری که یه جا درست حسابی بنویسی و بقیه جاها ازش استفاده کنی ، مثل احمقا همشو کپی پیست میکنی هر جا ک نیاز داری. خوانایی کد کم میشه ک هیچ ، انرژی اضافه تر میبره که هیچ ، اگر بخوای تغیرش هم بدی باید بری صد جا تغیرش بدی . تازه اگر یادت بمونه کجاهارو باس تغیر داد.
How do you write function like this
حالا چطوری توابعی به این تر و تمیزی بنویسیم که مو لا درزش نره ؟ نوشتن کد هم دقیقا مقل بقیه نوشتن هاست . وقتی میخوایم مقاله یا پاراگرافی رو تنظیم کنیم اول میریم سراغ یه پیشنویس . بعد که اون تموم شد میایم مشکلات و غلط هاشو رفع میکنیم . توابع هم همینطور حتما بعد از زمانی که کد داره کار میکنه باید به سراغش اومد و همه ی داستانای بالارو روش پیاده کرد . به مرور زمان این اصلاحات کم و کمتر میشه چون ما میدونیم چیا اشتباس و از همون اول مرتکب نمیشیم.
نتیجه و نصیحت
برنامه نویس های خفن اینطور فک میکنن که سیستم مثل یک داستانه که باید گفته بشه نه که نوشته بشه. توابع مثل افعال اون سیستم هستن . اگر قواعد رو پیروی کنید توابع کوتاه و خوش اسم و مشتی خواهید داشت ولی هدف اصلی شما اینه که داستان سیستمتون رو بگید ، پس توابعی ک مینویسید باید باهم همخونی داشته باشن تا به شما توی گفتن داستان کمک کنن.
وبسایت: https://mrbug.ir
تلگرام: https://www.t.me/mrbug_ir
اینستاگرام: https://www.instagram.com/mrbug_ir
