مهدی قوسیان
مهدی قوسیان
خواندن ۴ دقیقه·۴ سال پیش

از “data” به عنوان نام متغیر استفاده نکنید

فیل کارلتون می‌گوید: “فقط دو چیز سخت در علوم کامپیوتر وجود دارد: نامعتبر بودن حافظه پنهان و نام گذاری موارد.” ؛با کنار گذاشتن نامعتبر بودن حافظه پنهان که واقعا دشوار است، این جمله چیزی است که هر زمان در پیدا کردن نام مناسب به مشکل می‌خورم، در ذهن من به صدا درمی‌آید. نام گذاری صحیح برای کسی که نیاز به فهم سریع کد داشته باشد، چه در حال دیباگینگ و چه برای کمک به هم تیمی، از اهمیت بالایی برخوردار است. لازم نیست از کسی بپرسم منظور از users چیست، اما باید بپرسم که data به چه معناست. هرچند که خودم اغلب بهترین اسامی را پیدا نمی‌کنم، اما سعی دارم با رعایت برخی قوانین اساسی کد خود را برای خواننده بهینه کنم.

قوانین:

از پیشوندهای معنی‌دار استفاده کنید

اگرچه این پیشوندها جهانی نیستند، اما برای ایجاد یک زبان مشترک در تیم شما عالی هستند و استفاده مداوم از آنها در کد می‌تواند درک مطلب را آسان کند.

  • get، find، fetch برای توابعی که مقداری را برمی‌گردانند یا یک promise که بدون تغییر دادن استدلال‌ها به یک مقدار تبدیل می‌شود.
  • set، update برای توابعی که آرگومان‌ها را تغییر می‌دهند یا اعضا را فراخوانی می‌کنند. این توابع همچنین ممکن است مقدار به روز شده یا promise را که به مقدار به روز شده تغییر می‌کند، برگردانند.
  • on، handle برای توابع کنترل کننده رویداد. قرارداد تیم من این است که onEvent از طریق props به درون کامپوننت منتقل می‌شود و handleEvent در داخل کامپوننت تعریف می‌شود.
  • is، should، can برای متغیرها و توابع بولین با مقادیر برگشت بولی.

هر کنوانسیونی که در تیم شما استاندارد شود، می‌تواند به خوانایی شما کمک کند. مطمئن شوید که این موارد را در README یا wiki مستند کنید. ایجاد linterهای سفارشی برای اجرای این موارد حتی موثرتر خواهد بود.

از کلمات بامعنی استفاده کنید

به عنوان مثال توسعه‌دهندگان غالبا متغیرها را به طور پیش فرض data نامگذاری می‌کنند، اما بیایید چند تعریف از آنها را بررسی کنیم:

  • “اطلاعات واقعی (مانند اندازه‌گیری یا آمار) که به عنوان مبنایی برای استدلال، بحث یا محاسبه استفاده می‌شوند”
  • “اطلاعاتی که به شکل دیجیتال قابل انتقال یا پردازش‌اند”

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

function total(data) { let total = ۰; for (let i = ۰; i < data.length; i++) { total += data[i].value; } return total; }

می‌دانیم که این تابع در کل چیزی را محاسبه می‌کند، اما مطمئن نیستیم که آن چه چیزی است.

استثناها

گاهی اوقات متغیر می‌تواند شامل هر چیزی باشد، مانند بدنه پاسخ یک درخواست در شبکه. کتابخانه‌هایی مانند axios از data استفاده می‌کنند که در این مورد نام معقولی است. حتی در این سناریو، body بیشتر معنی می‌دهد و می‌تواند جایگزین شود. این همان چیزی است که web API fetch در Response خود از آن استفاده می‌کند.

از کلمات کامل استفاده کنید

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

مانند قبل، بیایید به تابعی نگاه کنیم که از این قانون پیروی نمی‌کند:

function totBal(accts) { let tot = ۰; for (let i = ۰; i < accts.length; i++) { tot += accts[i].bal; } return tot; }

در اینجا باید به ذهن خود فشار بیاوریم تا بتوانیم حدس بزنیم accts به معنای accounts و tot به معنای total است، اما نمی‌توانیم با یک نگاه کد را پردازش کنیم.

استثناها

اختصارات معمول در این حوزه بر فرم طولانی آنها ترجیح داده می‌شود (به عنوان مثالURL ، API ، CSS و موارد دیگر).

از کلمات ترکیبی طولانی استفاده نکنید

Container و Wrapper فقط در رابطه با چیزی که در آن قرار می‌گیرند معنی دارند. مسئله این است هر کامپوننتی که عنصر پایه نباشد، حاوی کامپوننت دیگری است. سرانجام شما در موقعیت نامناسبی قرار می‌گیرید و MyComponentContainerContainer را نامگذاری می‌کنید. در مورد Wrapper نیز همین مورد وجود دارد.

استثناها

در بعضی موارد، این کلمات ترکیبی و طولانی می‌توانند معنی قابل توجهی داشته باشند. الگوی رایج در کامپوننت‌های کلاس الگوی presentation/ container است. container در این حالت ممکن است یک کامپوننت را نشان دهد که state را در کامپوننت presentation مدیریت می‌کند. فقط مطمئن شوید که همیشه از آن برای این منظور استفاده کنید.

از غلط املایی پرهیز کنید

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

به کار گرفتن همه قوانین

با استفاده از همه قواعدی که تا اینجا گفته شد به طور همزمان، تابع زیر را دریافت می‌کنیم:

function getAccountsTotalBalance(accounts) { let totalBalance = ۰; for (let accountIndex = ۰; accountIndex < accounts.length; accountIndex++) { totalBalance += accounts[accountIndex].balance; } return totalBalance; }

هرچند ممکن است AccountIndex در مقابل i طولانی باشد، اما بقیه تابع بسیار واضح‌تر به نظر می‌رسد. getAccountsTotalBalance به طور کامل هدف تابع را اعلام می‌کند و پیشوند get نشان می‌دهد که منجر به ایجاد mutation نخواهد شد. ارزش دارد که توسعه دهنده کد در ازای منافع خواننده تلاش بیشتری را انجام دهد. خودتان نیز در آینده وقتی کد را ببینید، از این کار قدردانی خواهید کرد.

اگر نگران طول خط هستید، از ابزاری مانند Prettier برای قالب‌بندی خودکار کد استفاده کنید.

جمع‌بندی

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

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

برنامه نویسیuiuxطراحی وب سایتprogrammer
یه UI-UX کار و برنامه نویس Back-end عاشق کتاب
شاید از این پست‌ها خوشتان بیاید