‏راهنمای نام‌گذاری خوب در برنامه‌نویسی

آدام تورن‌هیل نام‌گذاری رو دومین مسئلهٔ سخت علوم کامپیوتر می‌دونه، ولی می‌گه این کار خیلی فراتر از سلیقه و زیباییه. به گفتهٔ نویسنده اسم‌ها یه جور «فشرده‌سازی ذهنی» هستن؛ وقتی اسم‌ها قوی باشن اطلاعات بیشتری تو ذهنت جا می‌گیره و راحت‌تر می‌فهمی یه کد ناآشنا چی‌کار می‌کنه. حتی به عدد هم اشاره می‌کنه: اسم‌های شفاف‌تر به‌تنهایی زمان دیباگ رو حدود ۱۹٪ کم می‌کنن و مدل‌های زبانی هم با اسم‌های بهتر، کد رو بهتر می‌فهمن.

یکی از نکته‌های اصلی مقاله اینه که اسم تابع رو باید برای «جای صدازدنش» بهینه کنی نه جای تعریفش، چون ما جای صدازدن یه تابع رو خیلی بیشتر از جای تعریفش می‌خونیم. نویسنده می‌گه بذار اسم‌ها کنار هم یه جمله بسازن تا کل اون فراخوانی مثل یه تیکهٔ معنایی تو ذهن جا بیفته:

notify_all(registered_clients, about=the_new_version)

برای رسیدن به همچین اسم‌هایی، ترفند موردعلاقه‌اش «تفکر آرزومندانه» (Wishful Thinking) هست که از کتاب کلاسیک SICP یاد گرفته: کد رو جوری بنویس انگار اون انتزاع از قبل وجود داشته، اول جملهٔ ایده‌آل رو بساز، بعد برو توابعش رو پیاده کن. یعنی اسم‌گذاری اول میاد، پیاده‌سازی بعد.

نویسنده به «وسواس نوع‌های اولیه» (primitive obsession) هم گیر می‌ده؛ وقتی مفهومی مثل زبان یا خبر رو با یه int خام مدل می‌کنی، هم سیستم نوع ضعیف می‌شه هم اسم پارامتر بی‌معنی می‌مونه. اگه نوع‌های دامنه‌ای درست بسازی، خود نوع می‌گه آرگومان چیه و اسم پارامتر آزاد می‌شه که بگه «چرا» اونجاست. یه قاعدهٔ دیگه‌اش هم اینه که طول اسم باید با محدوده‌اش جور باشه: تو یه حلقهٔ کوتاه یه i کافیه، ولی برای متغیر نمونه یا API عمومی باید اسم رو کامل بنویسی.

بخش دوم مقاله دربارهٔ عادت‌هاییه که به نظر نویسنده ضرر می‌زنن. می‌گه پیشوند I روی اینترفیس‌ها رو بردار، چون این‌که یه چیز اینترفیسه کم‌اهمیت‌ترین ویژگیشه و کاربر نباید درگیر نحوهٔ پیاده‌سازی بشه. سراغ getter و setter هم می‌ره و می‌گه پیشوندهای get و set معمولاً ارزشی اضافه نمی‌کنن و آدم رو به‌جای «گفتن»، به «پرسیدن» می‌کشونن؛ مثل این کد:

customer = get_customer(customer_id)
set_customer_status(customer, SUSPENDED)

به گفتهٔ نویسنده همین منطق رو بهتره ساده‌تر و مثل suspend(a_customer) مدل کرد. آخرین هشدارش هم دربارهٔ اسم‌های کلی و مبهم مثل Utils، Misc و Helper هست؛ می‌گه این اسم‌ها مثل سطل آشغال، کد بی‌کیفیت رو به خودشون جذب می‌کنن و هر بار وسوسه شدی یه کلاس Utils بسازی، یعنی داری از طراحی درست کوتاه میای.

نکات کلیدی:

• اسم خوب کار بازسازی ذهنی معنی کد رو کم می‌کنه، هم برای آدم هم برای ابزار هوش مصنوعی
• اسم تابع رو برای جای صدازدنش بهینه کن تا فراخوانی‌ها مثل جمله خونده بشن
• با نوع‌های دامنه‌ای، اسم پارامتر آزاد می‌شه که «چرا» رو بگه
• طول اسم باید با محدوده‌اش جور باشه: محدودهٔ کوچیک، اسم کوتاه
• از پیشوند I، getterها/setterها و کلاس‌های کلی مثل Utils دوری کن