Improved Persian translation of the 'code style' section

README-ir.md

@@ -32,9 +32,9 @@
 - [وابستگی‌ها (Dependencies)](#dependencies)
 - [تست کردن (Testing)](#testing)
 - [ساختار و نام‌گذاری (Structure and Naming)](#structure-and-naming)
-- [سبک کدنویسی/Code style](#code-style)
-  - [برخی از دستورالعمل‌های code style](#code-style-check)
-  - [اعمال استانداردهای سبک کدنویسی](#enforcing-code-style-standards)
+- [سبک کدنویسی (Code Style)](#code-style)
+  - [برخی اصول Code Style](#code-style-check)
+  - [اعمال استانداردهای کدنویسی](#enforcing-code-style-standards)
 - [ثبت وقایع/Logging](#logging)
 - [ای‌پی‌آی/API](#api)
   - [طراحی API](#api-design)
@@ -496,105 +496,107 @@ _چرا:_
 
 <a name="code-style"></a>
 
-## 7. سبک کدنویسی/Code style
+## 7. سبک کدنویسی (Code Style)
 
 <p align="right">
   <img src="/images/code-style.png" alt="Code style" width="128" height="128">
 </p>
 
 <a name="code-style-check"></a>
 
-### 7.1 برخی از اصول code style
+### 7.1 برخی اصول Code Style
 
-- برای پروژه‌های جدید از سینتکس جاوااسکریپت مدرن (استیج ۲ و بالاتر) استفاده کنید. برای پروژه‌های قدیمی، با سینتکس موجود سازگار بمانید مگر اینکه قصد به‌روزرسانی آن را داشته باشید.
+- در پروژه‌های جدید از ویژگی‌های جدید جاوااسکریپت (Stage 2 و بالاتر) بهره ببرید. برای پروژه‌های قدیمی، در صورت عدم تمایل به مهاجرت، سینتکس قبلی را حفظ کنید، مگر اینکه قصد به‌روزرسانی آن را داشته باشید.
 
 _چرا:_
 
-> این موضوع به تصمیم شما بستگی دارد. ما از مبدل‌ها (ترنسپایلرها) برای بهره‌گیری از مزایای سینتکس جدید استفاده می‌کنیم. استیج ۲ با تغییرات جزئی احتمالا بخشی از استاندارد خواهد شد.
+> این موضوع به تصمیم شما بستگی دارد. بهره‌گیری از ترنسپایلرها (مانند Babel) استفاده از قابلیت‌های جدید زبان را آسان می‌کند. ویژگی‌های Stage 2 معمولاً با تغییرات جزئی بخشی از استاندارد زبان خواهند شد.
 
-- اطمینان حاصل کنید که بررسی سبک کدنویسی (code style) به عنوان بخشی از فرآیند build پروژه انجام شود. (تا هماهنگی و استاندارد بودن کدها در تمام مراحل توسعه حفظ شود.)
+- از اجرای بررسی سبک کدنویسی (Code Style) به‌عنوان بخشی از فرآیند Build پروژه، اطمینان حاصل کنید.
 
 _چرا:_
 
-> متوقف کردن build برنامه یکی از روش‌های اعمال سبک کدنویسی در کد است. این کار از بی‌توجهی به سبک کدنویسی جلوگیری می‌کند. این روش را برای کد سمت client و server اجرا کنید. [توضیحات بیشتر ...](https://www.robinwieruch.de/react-eslint-webpack-babel/)
+> اگر خطاهای مربوط به سبک کدنویسی جلوی Build را بگیرند، توسعه‌دهندگان مجبور می‌شوند قوانین را رعایت کنند. این روش هم در کد سمت کاربر (Client) و هم در سمت سرور (Server) قابل اجراست. ([توضیحات بیشتر ...](https://www.robinwieruch.de/react-eslint-webpack-babel/))
 
-- برای اعمال سبک کدنویسی از [ESLint - ابزار بررسی سبک کدنویسی جاوااسکریپت](http://eslint.org/) استفاده کنید.
+- برای بررسی و اعمال سبک کدنویسی از [ESLint](http://eslint.org/) استفاده کنید.
 
 _چرا:_
 
 > ما `eslint` را ترجیح می‌دهیم، اما شما می‌توانید انتخاب دیگری داشته باشید. این ابزار قوانین بیشتری را پشتیبانی می‌کند، همچنین قابلیت تنظیم و افزودن قوانین سفارشی را دارد.
 
-- ما از کد استایل [Airbnb](https://github.com/airbnb/javascript) برای جاوااسکریپت استفاده می‌کنیم، [بیشتر بخوانید](https://www.gitbook.com/book/duk/airbnb-javascript-guidelines/details). از کد استایلی که پروژه یا تیم شما نیاز دارد استفاده کنید (تا کدهایتان با استانداردهای تعیین‌شده هماهنگ باشند).
-- ما هنگام استفاده از [FlowType](https://flow.org/) از [قوانین بررسی سبک تایپ Flow برای ESLint](https://github.com/gajus/eslint-plugin-flowtype) استفاده می‌کنیم.
+- ما از کد استایل [Airbnb](https://github.com/airbnb/javascript) برای جاوااسکریپت استفاده می‌کنیم، [بیشتر بخوانید](https://www.gitbook.com/book/duk/airbnb-javascript-guidelines/details). شما نیز می‌توانید هر کد استایلی که با نیاز پروژه یا تیمتان همخوانی دارد، به کار بگیرید.
+
+- هنگام استفاده از [FlowType](https://flow.org/)، از پلاگین‌های مربوط به بررسی [سبک کدنویسی Flow برای ESLint](https://github.com/gajus/eslint-plugin-flowtype) بهره ببرید.
 
 _چرا:_
 
-> ابزار Flow سینتکس‌های جدیدی را معرفی می‌کند که نیاز به رعایت سبک کدنویسی خاصی دارند و باید بررسی شوند.
+> با استفاده از Flow اعضای تیم باید سبک کدنویسی خاصی را رعایت کنند.
 
-- از فایل `.eslintignore` برای مستثنی کردن فایل‌ها یا پوشه‌ها از بررسی کد استایل استفاده کنید.
+- برای مستثنی‌کردن فایل‌ها و پوشه‌ها از بررسی سبک کدنویسی، از فایل `.eslintignore` استفاده کنید.
 
 _چرا:_
 
-> برای مستثنی کردن چند فایل از بررسی سبک کدنویسی، لازم نیست کدتان را با کامنت‌های `eslint-disable` شلوغ کنید.
+> به‌جای شلوغ کردن کد با کامنت‌های `eslint-disable`، برای مستثنی‌کردن فایل‌ها و پوشه‌ها از بررسی سبک کدنویسی، از فایل `.eslintignore` استفاده کنید.
 
-- قبل از ارسال یک Pull Request، تمام کامنت‌های `eslint-disable` خود را حذف کنید.
+- تمام کامنت‌های `eslint-disable` خود را پیش از ارسال یک Pull Request حذف کنید.
 
 _چرا:_
 
-> طبیعی است که هنگام کار بر روی یک بخش از کد، برای تمرکز بیشتر روی منطق، بررسی سبک را غیرفعال کنید. فقط به خاطر داشته باشید که کامنت‌های `eslint-disable` را حذف کرده و قوانین را رعایت کنید.
+> ممکن است گاهی برای افزایش تمرکز روی یک بخش از منطق کد (Logic)، موقتاً بررسی سبک را غیرفعال کنید؛ اما به خاطر داشته باشید که پیش از ارسال Pull Request، این کامنت‌ها را جهت مطابقت کد با استانداردهای مشخص شده، حذف کنید.
 
-- بسته به حجم و اندازه کار، از کامنت‌های `//TODO:` استفاده کنید یا یک تیکت باز کنید.
+- با در نظر داشتن حجم و اندازه کار، از کامنت‌های `//TODO:` یا ایجاد یک تیکت، استفاده کنید.
 
 _چرا:_
 
-> استفاده از کامنت‌های `//TODO:` به شما و همکارانتان کمک می‌کند تا وظایف کوچک مانند بازنویسی یک تابع یا به‌روزرسانی یک توضیح را به خاطر بسپارید. برای وظایف بزرگ‌تر، از فرمت `//TODO(#3456)` استفاده کنید که توسط قوانین lint اعمال می‌شود، که شماره‌ی داخل پرانتز به یک تیکت باز اشاره دارد.
+> استفاده از کامنت‌های `//TODO:` به شما و همکارانتان کمک می‌کند تا وظایف کوچک مانند بازنویسی یک تابع یا به‌روزرسانی یک توضیح را به خاطر بسپارند. برای وظایف بزرگ‌تر، از فرمت `//TODO(#3456)` که توسط قوانین `lint` اعمال می‌شود، استفاده کنید، که شماره‌ی داخل پرانتز به یک تیکت باز در سیستم مدیریت پروژه اشاره می‌کند.
 
-- همیشه کامنت‌ها را به‌روز و مرتبط با تغییرات کد نگه دارید. بخش‌های کامنت‌شده کد را حذف کنید.
+- همیشه کامنت‌ها را با تغییرات کد بروز نگه دارید. همچنین کدهایی که کامنت‌شده‌اند را نیز حذف کنید.
 
 _چرا:_
 
-> کد شما باید تا حد ممکن خوانا باشد؛ هر چیزی که حواس را پرت می‌کند، حذف کنید. اگر یک تابع را بازنویسی کردید، تابع قدیمی را فقط کامنت نکنید، بلکه آن را حذف کنید.
+> کد باید تا حد امکان خوانا باشد؛ بخش‌هایی از کد که استفاده نمی‌شوند را حذف کنید و کامنت‌ها را مطابق با تغییرات جدید به‌روزرسانی کنید. مثلاً اگر یک تابع را بازنویسی کردید، تابع قدیمی را فقط کامنت نکنید، بلکه آن را حذف کنید.
 
-- از کامنت‌ها، لاگ‌ها یا نام‌های نامرتبط یا طنزآمیز پرهیز کنید.
+- از نام‌ها یا کامنت‌های طنزآمیز یا غیرمرتبط پرهیز کنید.
 
 _چرا:_
 
-> اگرچه در فرآیند build برنامه آن‌ شوخی‌ها ممکن است (و بهتر است بگویم باید) حذف شود، اما گاهی source code شما به شرکت یا مشتری دیگری منتقل می‌شود که ممکن است آن‌ها چنین شوخی‌هایی را نپسندند.
+> اگرچه در فرآیند build برنامه، ممکن است آن کامنت‌ها و شوخی‌ها به صورت خودکار حذف شوند، اما در برخی موارد سورس کد به سایر شرکت‌ها یا مشتری‌ها منتقل می‌شود که ممکن است آن‌ها این نوع شوخی‌ها را نپسندند.
 
-- نام‌ها را به گونه‌ای انتخاب کنید که قابل جست‌وجو و دارای تفاوت‌های معنادار باشند و از نام‌های کوتاه‌شده و مخفف بپرهیزید. برای توابع، از نام‌های طولانی و توصیفی استفاده کنید. نام تابع باید یک فعل یا عبارت فعلی باشد و هدف آن را به وضوح بیان کند.
+- نام‌ها را به گونه‌ای انتخاب کنید که قابل جست‌وجو و معنادار باشند، از انتخاب نام‌های کوتاه‌شده و مخفف بپرهیزید. برای توابع، از نام‌های توصیفی و فعل‌محور استفاده کنید. نام تابع باید یک فعل یا عبارت فعلی باشد و هدف آن را به وضوح بیان کند.
 
 _چرا:_
 
 > این کار (استفاده از نام‌های کامل و توصیفی) باعث می‌شود کد خواناتر و درک آن راحت‌تر و ساده‌تر شود.
 
-- توابع خود را در فایل بر اساس «قانون نزولی» (Step-down Rule) سازمان‌دهی کنید؛ به این صورت که توابع سطح بالاتر در بالای فایل و توابع سطح پایین‌تر در زیر آن‌ها قرار گیرند.
+- توابع را بر اساس «قانون نزولی» (Step-Down Rule) سازمان‌دهی کنید؛ به این صورت که توابع سطح بالاتر را در بالای فایل و توابع سطح پایین‌تر را در پایین فایل قرار دهید.
 
 _چرا:_
 
-> این کار کد را خواناتر و درک آن بهتر می‌کند
+> این کار خوانایی کد را افزایش می‌دهد.
 
 <a name="enforcing-code-style-standards"></a>
 
 ### 7.2 اعمال استانداردهای سبک کدنویسی
 
-- از فایل [.editorconfig](http://editorconfig.org/) استفاده کنید که به توسعه‌دهندگان کمک می‌کند تا سبک‌های کدنویسی یکسانی را بین ویرایشگرها و IDEهای مختلف پروژه تعریف و حفظ کنند.
+- از فایل `.editorconfig` استفاده کنید ([لینک](http://editorconfig.org/)) که به شما و سایر اعضای تیم کمک کند تا سبک‌های کدنویسی یکسانی را میان ویرایشگرها و IDEهای مختلف پروژه تعریف و حفظ کنید.
 
 _چرا:_
 
-> پروژه EditorConfig شامل یک فرمت فایل برای تعریف سبک‌ و استال‌های کدنویسی است که شامل مجموعه‌ای از افزونه‌ها برای ویرایشگرهای متنی است، که به ویرایشگرها این امکان را می‌دهد تا فرمت فایل را بخوانند و از استایل‌های تعریف‌شده پیروی کنند. فایل‌های EditorConfig خوانا هستند و به‌خوبی با سیستم‌های کنترل نسخه کار می‌کنند.
+> پروژه `EditorConfig` دربرگیرنده‌ی یک فایل برای تعریف سبک‌ و استال‌های کدنویسی است که شامل مجموعه‌ای از افزونه‌ها برای ویرایشگرها و IDEی مختلف است؛ که این امکان را می‌دهد که ویرایشگرها و IDEی مختلف از استایل‌های تعریف‌شده پیروی کنند.
+
+- ویرایشگر را به شیوه‌ای راه‌اندازی و تنظیم کنید که برای خطاهای سبک کدنویسی (Code Style) هشدار دهد. از ترکیب پلاگین‌های [eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier) و [eslint-config-prettier](https://github.com/prettier/eslint-config-prettier) در تنظیمات ESLint خود استفاده کنید. ([توضیحات بیشتر ...](https://github.com/prettier/eslint-config-prettier#installation))
 
-- ویرایشگر خود را طوری تنظیم کنید که به شما در مورد خطاهای سبک کدنویسی اطلاع دهد. از [eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier) و [eslint-config-prettier](https://github.com/prettier/eslint-config-prettier) همراه با پیکربندی ESLint خود استفاده کنید. [توضیحات بیشتر ...](https://github.com/prettier/eslint-config-prettier#installation)
-- استفاده از Git hooks را مدنظر قرار دهید.
+- - استفاده از Git hooks را مدنظر قرار دهید.
 
 _چرا:_
 
-> استفاده از Git hooks به‌طور قابل‌توجهی بهره‌وری توسعه‌دهندگان را افزایش می‌دهد. با اعمال تغییرات، انجام commit و ارسال (push) به محیط‌های staging یا production، بدون نگرانی از خراب شدن build برنامه، می‌توانید با اطمینان بیشتری کار کنید. [توضیحات بیشتر ...](http://githooks.com/)
+> با اجرای خودکار تست‌ها و بررسی Code Style پیش از Commit یا Push کردن تغییرات، می‌توانید مشکلات احتمالی را زودتر شناسایی کنید و از شکست Build پروژه در محیط‌‌های Staging یا Production جلوگیری کنید. ([توضیحات بیشتر ...](http://githooks.com/))
 
-- از Prettier همراه با یک precommit hook استفاده کنید.
+- از Prettier همراه با precommit hook استفاده کنید.
 
 _چرا:_
 
-> اگرچه `prettier` به‌خودی‌خود قدرتمند است، اجرای دستی آن به‌عنوان یک تسک npm برای قالب‌بندی کد چندان کارآمد نیست. در اینجا `lint-staged` (و `husky`) وارد عمل می‌شوند. درباره پیکربندی `lint-staged` [اینجا](https://github.com/okonet/lint-staged#configuration) و پیکربندی `husky` [اینجا](https://github.com/typicode/husky) بیشتر بخوانید..
+> اگرچه `prettier` به‌خودی‌خود قدرتمند است، اما اجرای دستی `prettier` چندان کارآمد نیست. با بهره‌گیری از `lint-staged` و `husky`، می‌توانید هنگام Commit، کد را به‌صورت خودکار قالب‌بندی کنید. درباره پیکربندی `lint-staged` ([اینجا](https://github.com/okonet/lint-staged#configuration)) و پیکربندی `husky` ([اینجا](https://github.com/typicode/husky)) می‌توانید بیشتر مطالعه کنید.
 
 <a name="logging"></a>