جوری کد بنویس که بشه خوند...!

همیشه یکی از بزرگ‌ترین مشکلات در برنامه‌نویسی تیمی و گروهی، ناخوانا یا نامفهوم بودن کدهاست. چون معمولا استایل کدزنی ما با هم فرق می‌کنه، مثلا یکی تب میزنه یکی اسپیس. یا در اکثر مواقع، ما نمی‌تونیم کدهای هم‌دیگه رو بخونیم و بفهمیم و درک کنیم. البته همیشه نوشتن کد از خوندنش راحت‌تره و این از اول بوده؛ چون منطقاً فکر کردن از خوندن فکر دیگران راحت‌تره، نیست؟

یکی‌کردن استایل‌ها

تو این دست از مشکلات، ادیتورها به‌کمکمون میان. مثلا همون قضیه تب و اسپیس که گفتم رو میشه با یه فایل .editorconfig حل کرد! ادیتورکانفیگ یه فایل کوچولو و جمع‌وجوره که اکثر ادیتورا اگه اینو توی فایلاتون پیدا کنن، بهش عمل می‌کنن و از استایل اون پیروی می‌کنن. اکثر ادیتورا ساپورتش می‌کنن؛ اگر هم نکنن، پلاگینش قطعاً پیدا میشه. این یه مثال از ادیتورکانفیگ:

root = true  
# every file with any format
[*]
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
# use spaces instead of tabs
indent_style = space
# adjust indent size to 2
indent_size = 2
# settings for every .js file in test directory
[test/**.js]
indent_size = 4

به‌همین سادگی، ما یه استایل واحد داریم که همه ازش پیروی می‌کنن!

اهمیت کامنت‌ها

شاید کامنت‌ها به‌صورت تئوریک بی‌اهمیت باشن چون کامپایلر یا موتور یا ... اونا رو به‌حساب نمیاره؛ اما ما کامپایلر نیستیم. کامنت‌ها می‌تونن درواقع نقش داکیومنشن داشته‌باشن.
کد زیر رو فرض کنید:

module.exports = function(t) {
    return t.replace(/\s+/g, '-').replace(/&/g, '-and-').replace(/[^a-zA-Z-]+/g, '').replace(/\-\-+/, '-').replace(/^\-|\-$/g, '').toLowerCase().trim()
}

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

  • خب، این قراره چیکار کنه؟ من سردرنمیارم.
  • الان چه آرگومنتی باید بهش بدم؟
  • چی قراره بهم برگردونه؟

خب، باید بهش حق بدیم. اتکا به خود کد برای قابل‌فهم بودن کافی نیست، باید همه‌جا کامنت گذاشت تا درکش ساده‌تر بشه.
حالا بذارید یکم کامنت بهش اضافه کنیم:

// gets string, converts it to slug, returns it.

خب، الان با همین یه‌خط کامنت، پیشرفت چشمگیری داشتیم.
حالا اگه بخوایم یکم حرفه‌ای‌تر برخورد کنیم، اینطوری می‌نویسیم:

/**
 * Converts string to slug string.
 * @param {string} t
 * @returns {string} Slug String
 */

خب، الان اگه ادیتورتون یکم فهم داشته‌باشه، خودش اینا رو بهتون پیشنهاد میده!

همین فانکشن رو تو VSCode نوشتم؛ نتیجه رو ببینید :)
همین فانکشن رو تو VSCode نوشتم؛ نتیجه رو ببینید :)

و به‌همین زیبایی، کدهای ما خواناتر و قابل‌فهم‌تر شدند!
امیدوارم این مطلب به‌دردتون بخوره‌ :)