جوگیرساختن مخاطب برای خواندن تا ته

خب از شما بعد از خوندن این فصل انتظار میره که دیگه به هیچ عنوان تابع های طولانی و کشنده ننویسین، تابع های تودرتو را فراموش کرده و هرچی تابع دارید هیچ اثر جانبی نداشته باشه . اسم گذاری و تعداد ورودی های تابع هم جزو بازی هست . پس بریم و گوش بسپاریم به این فصل دلنواز :

فصل سوم – Functions

Small

اولین قانون اینه که توابعت کوچولو باشن، دومین قانون  اینه که کوچولوتر از اولی

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

Indent

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

Just one thing

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

 حالا شبهه ای که پیش میاد:

یه تابع هست رییس جمهور بعدی آمریکا رو پیشبینی میکنه

یه تابع هم هست دو تا عدد رو جمع میکنه .

الان ینی اینا جفتشون درست ان؟ قاعدتا نه . یه چیزی باید باشه که درستی  این یدونه کار رو تعیین کنه. این دوراه نشون میده که تابعت یه کار رو نمیکنه  :

  • بتونی یه تابع دیگه ازش استخراج کنی و اسم تابع جدید ربطی به تابع قبلی نداشته باشه .
  • سطح انتزاع (abstraction) کل  بدنه ی تابع یک سطح پایین تر از تعریف تابع نباشه . مثلا فرض کنید تابعی به اسم پخت کیک وجود داره و بدنش شامل شکستن تخم‌مرغ ، ریختن شیر ، مخلوط شیر و تخم‌مرغه. الان تابع پخت کیک یه کار رو نمیکنه چون این فانکشن آخریه سطح اتنزاعش با دوتای قبلیش فرق داره پس باید بره توی یک تابع دیگه. حله؟

One Level of Abstraction per Function

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

Reading Code from Top to Bottom: The Stepdown Rule

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

Switch Statements

اینجا میخواد یکاری کنه که هر وقت از سووییچ استفاده میکنی عذاب وجدان بگیری . دلایلش ایناس :

  • تابع رو طولانی میکنه
  • معلوم نیس کیس ها ثابت باشن و قطعا در ادامه ی کار بیشتر و بیشتر میشن
  • خدشه دار کردن اصل single responsibility به این دلیل که بیشتر از یک دلیل برای تغیر اون وجود داره 
  • ممکنه خیلی از توابع دیگه هم به این ساختار احتیاج داشته باشن

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

Use Descriptive Names

Descriptive  به این معناس که اسمش دقیقا کار تابع رو توضیح بده و اصلا هم از طولانی شدنش نترسید (البته شورشم در نیارید) . از اینکه وقت زیادی صرف انتخاب اسم بکنید هم نترسید .

Function Arguments

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

به عنوان مثال  اگر گوش شیطون کر  خواستی بیشتر از سه تا آرگومان بدی میتونی ورودی‌هارو یه آبجکت کنی و به تابعت پاس بدی یا اگر همشون یه جنسن به صورت آرایه بپاس .

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

Side effects

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

Command query sepration

تابع یا باید یه کاریو انجام بده واست یا یه جوابی بهت بده . دوتاش همزمان باشه توی کد ابهام ایجاد میکنه. مثلا یه تابع داریم که چک میکنه اگر یوزر نیم وجود نداشت ، بسازش و به عموباب تغیرش بده.

 یه بدبختی داره کدتو میخونه و میرسه به این خط :

If(Set(“username”,”uncleBob”))

خب حالا طرف چه فکری راجع بهش میکنه:

  • آیا یوزرنیم قبلا به عموباب ست شده؟
  • آیا ست شدن عموباب به عنوان یوزرنیم موفقیت آمیز بوده؟
  • 3.  …

اینجا مشکل هم انتخاب اسم تابعس هم همون داستان همیشگی که تابع داره دوتا کار میکنه . اینطوری مشکل رو حل میکنیم :

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

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

نتیجه و نصیحت

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

انسان سنتی خود را پیچیده و جهان را ساده میبیند !

دیدگاه خود را بنویسید:

آدرس ایمیل شما نمایش داده نخواهد شد.

فوتر سایت