با اصول کد تمیز برای بهبود خوانایی و نگهداری در توسعه نرم‌افزار، که به نفع جامعه جهانی برنامه‌نویسان است، آشنا شوید.
کد تمیز: هنر پیاده‌سازی خوانا برای جامعه جهانی توسعه‌دهندگان
در دنیای پویا و به‌هم‌پیوسته توسعه نرم‌افزار، توانایی نوشتن کدی که نه تنها کاربردی است، بلکه توسط دیگران نیز به راحتی قابل درک است، از اهمیت بالایی برخوردار است. این جوهر کد تمیز (Clean Code) است – مجموعه‌ای از اصول و شیوه‌هایی که بر خوانایی، قابلیت نگهداری و سادگی در پیاده‌سازی نرم‌افزار تأکید دارند. برای جامعه جهانی توسعه‌دهندگان، پذیرش کد تمیز فقط یک موضوع سلیقه‌ای نیست؛ بلکه یک الزام اساسی برای همکاری مؤثر، چرخه‌های توسعه سریع‌تر و در نهایت، ایجاد راه‌حل‌های نرم‌افزاری قوی و مقیاس‌پذیر است.
چرا کد تمیز در سطح جهانی اهمیت دارد؟
تیم‌های توسعه نرم‌افزار به طور فزاینده‌ای در کشورها، فرهنگ‌ها و مناطق زمانی مختلف پراکنده شده‌اند. این توزیع جهانی، نیاز به یک زبان و درک مشترک در پایگاه کد را تقویت می‌کند. وقتی کد تمیز باشد، مانند یک نقشه جهانی عمل می‌کند و به توسعه‌دهندگان با پیشینه‌های مختلف اجازه می‌دهد تا به سرعت هدف آن را درک کنند، مشکلات احتمالی را شناسایی کرده و بدون نیاز به دوره‌های آموزشی طولانی یا شفاف‌سازی مداوم، به طور مؤثر مشارکت کنند.
سناریویی را در نظر بگیرید که در آن یک تیم توسعه شامل مهندسانی در هند، آلمان و برزیل است. اگر پایگاه کد شلوغ، با فرمت‌بندی ناسازگار و استفاده از قراردادهای نام‌گذاری مبهم باشد، اشکال‌زدایی یک ویژگی مشترک می‌تواند به یک مانع بزرگ تبدیل شود. هر توسعه‌دهنده ممکن است کد را به طور متفاوتی تفسیر کند که منجر به سوءتفاهم‌ها و تأخیرها می‌شود. در مقابل، کد تمیز که با وضوح و ساختار خود مشخص می‌شود، این ابهامات را به حداقل می‌رساند و یک محیط تیمی منسجم‌تر و پربارتر را ترویج می‌کند.
ارکان کلیدی کد تمیز برای خوانایی
مفهوم کد تمیز، که توسط رابرت سی. مارتین (عمو باب) محبوب شد، شامل چندین اصل اساسی است. بیایید به مهم‌ترین آنها برای دستیابی به پیاده‌سازی خوانا بپردازیم:
۱. نام‌های معنادار: اولین خط دفاعی
نام‌هایی که برای متغیرها، توابع، کلاس‌ها و فایل‌ها انتخاب می‌کنیم، راه اصلی ما برای انتقال قصد کدمان هستند. در یک زمینه جهانی، که انگلیسی اغلب زبان مشترک است اما ممکن است زبان مادری همه نباشد، وضوح حتی از اهمیت بیشتری برخوردار است.
- نیت را آشکار کنید: نام‌ها باید به وضوح نشان دهند که یک موجودیت چه کاری انجام می‌دهد یا چه چیزی را نشان می‌دهد. به عنوان مثال، به جای `d` برای روز، از `elapsedDays` استفاده کنید. به جای `process()` برای یک عملیات پیچیده، از `processCustomerOrder()` یا `calculateInvoiceTotal()` استفاده کنید.
- از کدگذاری‌ها اجتناب کنید: اطلاعاتی را که می‌توان از زمینه استنباط کرد، مانند نمادگذاری مجارستانی (مثلاً `strName`, `iCount`)، درج نکنید. IDEهای مدرن اطلاعات نوع را ارائه می‌دهند و این‌ها را اضافی و اغلب گیج‌کننده می‌سازند.
- تمایزهای معنادار ایجاد کنید: از استفاده از نام‌هایی که بیش از حد شبیه هستند یا فقط با یک کاراکتر یا عدد دلخواه تفاوت دارند، خودداری کنید. به عنوان مثال، `Product1`, `Product2` اطلاعات کمتری نسبت به `ProductActive`, `ProductInactive` دارند.
- از نام‌های قابل تلفظ استفاده کنید: اگرچه در زمینه‌های بسیار فنی همیشه امکان‌پذیر نیست، نام‌های قابل تلفظ می‌توانند به ارتباط کلامی در طول بحث‌های تیمی کمک کنند.
- از نام‌های قابل جستجو استفاده کنید: نام‌های متغیر تک‌حرفی یا اختصارات مبهم می‌توانند در یک پایگاه کد بزرگ به سختی پیدا شوند. نام‌های توصیفی را انتخاب کنید که با استفاده از قابلیت‌های جستجو به راحتی پیدا شوند.
- نام کلاس‌ها: باید اسم یا عبارت اسمی باشند و اغلب یک مفهوم یا موجودیت را نشان دهند (مثلاً `Customer`, `OrderProcessor`, `DatabaseConnection`).
- نام متدها: باید فعل یا عبارت فعلی باشند و عملی را که متد انجام می‌دهد توصیف کنند (مثلاً `getUserDetails()`, `saveOrder()`, `validateInput()`).
مثال جهانی: تیمی را تصور کنید که روی یک پلتفرم تجارت الکترونیک کار می‌کند. متغیری به نام `custInfo` ممکن است مبهم باشد. آیا این اطلاعات مشتری، شاخص هزینه یا چیز دیگری است؟ یک نام توصیفی‌تر مانند `customerDetails` یا `shippingAddress` هیچ جایی برای تفسیر اشتباه باقی نمی‌گذارد، صرف نظر از پیشینه زبانی توسعه‌دهنده.
۲. توابع: کوچک، متمرکز و تک‌منظوره
توابع، بلوک‌های سازنده هر برنامه‌ای هستند. توابع تمیز، کوتاه هستند، یک کار را انجام می‌دهند و آن را به خوبی انجام می‌دهند. این اصل باعث می‌شود که درک، آزمایش و استفاده مجدد از آنها آسان‌تر شود.
- کوچک بودن: سعی کنید توابعی بنویسید که بیش از چند خط طول نداشته باشند. اگر یک تابع بزرگ شود، این نشانه‌ای است که ممکن است کارهای زیادی انجام دهد و می‌تواند به واحدهای کوچکتر و قابل مدیریت‌تر تقسیم شود.
- یک کار انجام دهید: هر تابع باید یک هدف واحد و به خوبی تعریف شده داشته باشد. اگر یک تابع چندین وظیفه متمایز را انجام می‌دهد، باید به توابع جداگانه بازآرایی (refactor) شود.
- نام‌های توصیفی: همانطور که قبلاً ذکر شد، نام توابع باید به وضوح هدف خود را بیان کنند.
- بدون عوارض جانبی (Side Effects): یک تابع باید در حالت ایده‌آل عمل مورد نظر خود را بدون تغییر وضعیت خارج از محدوده خود انجام دهد، مگر اینکه این هدف صریح آن باشد (مثلاً یک متد setter). این امر کد را قابل پیش‌بینی و استدلال در مورد آن را آسان‌تر می‌کند.
- آرگومان‌های کمتر را ترجیح دهید: توابع با آرگومان‌های زیاد می‌توانند دست‌وپاگیر و فراخوانی صحیح آنها دشوار شود. در صورت لزوم، گروه‌بندی آرگومان‌های مرتبط در اشیاء یا استفاده از الگوی سازنده (builder pattern) را در نظر بگیرید.
- از آرگومان‌های پرچمی (Flag Arguments) اجتناب کنید: پرچم‌های بولی اغلب نشان می‌دهند که یک تابع در تلاش است کارهای زیادی انجام دهد. به جای آن، ایجاد توابع جداگانه برای هر مورد را در نظر بگیرید.
مثال جهانی: تابعی مانند `calculateShippingAndTax(order)` را در نظر بگیرید. این تابع احتمالاً دو عملیات متمایز را انجام می‌دهد. تمیزتر خواهد بود که آن را به `calculateShippingCost(order)` و `calculateTax(order)` بازآرایی کرده و سپس یک تابع سطح بالاتر داشته باشیم که هر دو را فراخوانی کند.
۳. کامنت‌ها: زمانی که کلمات قاصرند، اما نه خیلی زیاد
کامنت‌ها باید برای توضیح چرا کاری انجام می‌شود استفاده شوند، نه چه کاری انجام می‌شود، زیرا خود کد باید 'چه' را توضیح دهد. کامنت‌گذاری بیش از حد می‌تواند کد را شلوغ کرده و اگر به‌روز نگه داشته نشود، به یک بار نگهداری تبدیل شود.
- توضیح نیت: از کامنت‌ها برای روشن کردن الگوریتم‌های پیچیده، منطق تجاری یا دلیل پشت یک انتخاب طراحی خاص استفاده کنید.
- اجتناب از کامنت‌های اضافی: کامنت‌هایی که صرفاً آنچه را که کد انجام می‌دهد تکرار می‌کنند (مثلاً `// افزایش شمارنده`) غیر ضروری هستند.
- کامنت‌گذاری خطاها، نه فقط کد: گاهی اوقات، ممکن است مجبور شوید به دلیل محدودیت‌های خارجی، کدی بنویسید که ایده‌آل نیست. یک کامنت که این موضوع را توضیح می‌دهد می‌تواند بسیار ارزشمند باشد.
- کامنت‌ها را به‌روز نگه دارید: کامنت‌های قدیمی بدتر از نبودن کامنت هستند، زیرا می‌توانند توسعه‌دهندگان را گمراه کنند.
مثال جهانی: اگر یک قطعه کد خاص باید به دلیل یکپارچه‌سازی با یک سیستم قدیمی، یک بررسی امنیتی استاندارد را دور بزند، یک کامنت که این تصمیم را توضیح می‌دهد، همراه با ارجاع به ردیاب مشکل مربوطه، برای هر توسعه‌دهنده‌ای که بعداً با آن مواجه می‌شود، صرف نظر از پیشینه امنیتی آنها، حیاتی است.
۴. قالب‌بندی و تورفتگی: ساختار بصری
قالب‌بندی منسجم، کد را از نظر بصری سازمان‌یافته و پیمایش آن را آسان‌تر می‌کند. در حالی که راهنماهای سبک خاص ممکن است بر اساس زبان یا تیم متفاوت باشند، اصل اساسی، یکنواختی است.
- تورفتگی منسجم: از فاصله‌ها یا تب‌ها به طور منسجم برای مشخص کردن بلوک‌های کد استفاده کنید. اکثر IDEهای مدرن را می‌توان برای اعمال این مورد پیکربندی کرد.
- فضای خالی (Whitespace): از فضای خالی به طور مؤثر برای جدا کردن بلوک‌های منطقی کد در یک تابع استفاده کنید تا خوانایی آن بیشتر شود.
- طول خط: خطوط را به طور معقول کوتاه نگه دارید تا از پیمایش افقی که می‌تواند جریان خواندن را مختل کند، جلوگیری شود.
- سبک آکولاد: یک سبک منسجم برای آکولادها (مانند K&R یا Allman) انتخاب کنید و به آن پایبند باشید.
مثال جهانی: ابزارهای قالب‌بندی خودکار و لینترها در تیم‌های جهانی بسیار ارزشمند هستند. آنها به طور خودکار یک راهنمای سبک از پیش تعریف شده را اعمال می‌کنند و از سازگاری در تمام مشارکت‌ها، صرف نظر از ترجیحات فردی یا عادات کدنویسی منطقه‌ای، اطمینان حاصل می‌کنند. ابزارهایی مانند Prettier (برای جاوا اسکریپت)، Black (برای پایتون) یا gofmt (برای Go) نمونه‌های عالی هستند.
۵. مدیریت خطا: زیبا و آموزنده
مدیریت خطای قوی برای ساختن نرم‌افزار قابل اعتماد حیاتی است. مدیریت خطای تمیز شامل سیگنال‌دهی واضح خطاها و ارائه زمینه کافی برای حل آنها است.
- استفاده مناسب از استثناها (Exceptions): استثناها در بسیاری از زبان‌ها به جای بازگرداندن کدهای خطا ترجیح داده می‌شوند، زیرا آنها به وضوح جریان اجرای عادی را از مدیریت خطا جدا می‌کنند.
- ارائه زمینه: پیام‌های خطا باید آموزنده باشند و توضیح دهند که چه چیزی و چرا اشتباه رخ داده است، بدون اینکه جزئیات داخلی حساس را افشا کنند.
- مقدار null را برنگردانید: بازگرداندن `null` می‌تواند منجر به خطاهای NullPointerException شود. در صورت امکان، بازگرداندن مجموعه‌های خالی یا استفاده از انواع اختیاری (optional types) را در نظر بگیرید.
- انواع استثنای خاص: از انواع استثنای خاص به جای انواع عمومی استفاده کنید تا امکان مدیریت خطای هدفمندتری فراهم شود.
مثال جهانی: در یک برنامه کاربردی که پرداخت‌های بین‌المللی را مدیریت می‌کند، پیام خطایی مانند «پرداخت ناموفق بود» کافی نیست. یک پیام آموزنده‌تر، مانند «مجوز پرداخت ناموفق بود: تاریخ انقضای کارت برای کارتی که با XXXX به پایان می‌رسد نامعتبر است»، جزئیات لازم را برای کاربر یا کارکنان پشتیبانی برای رسیدگی به مشکل، صرف نظر از تخصص فنی یا موقعیت مکانی آنها، فراهم می‌کند.
۶. اصول SOLID: ساخت سیستم‌های قابل نگهداری
در حالی که اصول SOLID (تک مسئولیتی، باز/بسته، جایگزینی لیسکوف، تفکیک رابط، وارونگی وابستگی) اغلب با طراحی شی‌گرا مرتبط هستند، روح آنها در ایجاد کدی جدا از هم (decoupled)، قابل نگهداری و قابل توسعه، به طور جهانی قابل اجرا است.
- اصل تک مسئولیتی (SRP): یک کلاس یا ماژول باید تنها یک دلیل برای تغییر داشته باشد. این با اصل انجام یک کار توسط توابع همسو است.
- اصل باز/بسته (OCP): موجودیت‌های نرم‌افزاری (کلاس‌ها، ماژول‌ها، توابع و غیره) باید برای توسعه باز اما برای تغییر بسته باشند. این امر قابلیت توسعه را بدون معرفی رگرسیون ترویج می‌کند.
- اصل جایگزینی لیسکوف (LSP): زیرنوع‌ها باید بتوانند جایگزین انواع پایه خود شوند بدون اینکه صحت برنامه را تغییر دهند. این تضمین می‌کند که سلسله مراتب ارث‌بری به خوبی رفتار می‌کنند.
- اصل تفکیک رابط (ISP): کلاینت‌ها نباید مجبور به وابستگی به رابط‌هایی شوند که از آنها استفاده نمی‌کنند. رابط‌های کوچکتر و خاص‌تر را ترجیح دهید.
- اصل وارونگی وابستگی (DIP): ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابسته باشند. هر دو باید به انتزاعات (abstractions) وابسته باشند. انتزاعات نباید به جزئیات وابسته باشند. جزئیات باید به انتزاعات وابسته باشند. این برای قابلیت آزمایش و انعطاف‌پذیری کلیدی است.
مثال جهانی: سیستمی را تصور کنید که باید از درگاه‌های پرداخت مختلف (مانند Stripe، PayPal، Adyen) پشتیبانی کند. پایبندی به OCP و DIP به شما امکان می‌دهد تا با ایجاد یک پیاده‌سازی جدید از یک رابط مشترک `PaymentGateway`، یک درگاه پرداخت جدید اضافه کنید، به جای اینکه کد موجود را تغییر دهید. این باعث می‌شود سیستم با نیازهای بازار جهانی و فناوری‌های پرداخت در حال تحول سازگار باشد.
۷. اجتناب از تکرار: اصل DRY
اصل DRY (خودتان را تکرار نکنید) برای کد قابل نگهداری اساسی است. کد تکراری احتمال خطا را افزایش می‌دهد و به‌روزرسانی‌ها را زمان‌برتر می‌کند.
- شناسایی الگوهای تکراری: به دنبال بلوک‌های کدی باشید که چندین بار ظاهر می‌شوند.
- استخراج به توابع یا کلاس‌ها: منطق تکراری را در توابع، متدها یا کلاس‌های قابل استفاده مجدد کپسوله کنید.
- استفاده از فایل‌های پیکربندی: از کدنویسی مقادیری که ممکن است تغییر کنند (hardcoding) خودداری کنید؛ آنها را در فایل‌های پیکربندی ذخیره کنید.
مثال جهانی: یک برنامه وب را در نظر بگیرید که تاریخ و زمان را نمایش می‌دهد. اگر منطق قالب‌بندی تاریخ‌ها در چندین مکان (مثلاً پروفایل‌های کاربر، تاریخچه سفارشات) تکرار شود، می‌توان یک تابع واحد `formatDateTime(timestamp)` ایجاد کرد. این تضمین می‌کند که تمام نمایش‌های تاریخ از یک قالب استفاده می‌کنند و به‌روزرسانی قوانین قالب‌بندی را در سطح جهانی در صورت نیاز آسان می‌کند.
۸. ساختارهای کنترلی خوانا
نحوه ساختاردهی حلقه‌ها، شرطی‌ها و سایر مکانیسم‌های جریان کنترل به طور قابل توجهی بر خوانایی تأثیر می‌گذارد.
- کاهش تودرتویی (Nesting): دنبال کردن دستورات `if-else` یا حلقه‌های عمیقاً تودرتو دشوار است. آنها را به توابع کوچکتر بازآرایی کنید یا از guard clauses استفاده کنید.
- استفاده از شرطی‌های معنادار: متغیرهای بولی با نام‌های توصیفی می‌توانند درک شرایط پیچیده را آسان‌تر کنند.
- ترجیح `while` بر `for` برای حلقه‌های نامحدود: وقتی تعداد تکرارها از قبل مشخص نیست، یک حلقه `while` اغلب گویاتر است.
مثال جهانی: به جای یک ساختار `if-else` تودرتو که ممکن است تجزیه آن دشوار باشد، استخراج منطق به توابع جداگانه با نام‌های واضح را در نظر بگیرید. به عنوان مثال، یک تابع `isUserEligibleForDiscount(user)` می‌تواند بررسی‌های پیچیده واجد شرایط بودن را کپسوله کند و منطق اصلی را تمیزتر سازد.
۹. تست واحد: تضمین تمیزی
نوشتن تست‌های واحد بخش جدایی‌ناپذیر کد تمیز است. تست‌ها به عنوان مستندات زنده و یک شبکه ایمنی در برابر رگرسیون‌ها عمل می‌کنند و تضمین می‌کنند که تغییرات عملکرد موجود را خراب نمی‌کنند.
- کد قابل آزمایش: اصول کد تمیز، مانند SRP و پایبندی به SOLID، به طور طبیعی به کدی قابل آزمایش‌تر منجر می‌شوند.
- نام‌های تست معنادار: نام‌های تست باید به وضوح نشان دهند که چه سناریویی در حال آزمایش است و نتیجه مورد انتظار چیست.
- Arrange-Act-Assert: تست‌های خود را به وضوح با فازهای متمایز برای آماده‌سازی، اجرا و تأیید ساختار دهید.
مثال جهانی: یک مؤلفه به خوبی آزمایش شده برای تبدیل ارز، با تست‌هایی که جفت ارزهای مختلف و موارد مرزی (مانند مقادیر صفر، منفی، نرخ‌های تاریخی) را پوشش می‌دهند، به توسعه‌دهندگان در سراسر جهان اطمینان می‌دهد که مؤلفه همانطور که انتظار می‌رود رفتار خواهد کرد، حتی هنگام کار با تراکنش‌های مالی متنوع.
دستیابی به کد تمیز در یک تیم جهانی
پیاده‌سازی مؤثر شیوه‌های کد تمیز در یک تیم توزیع شده نیازمند تلاش آگاهانه و فرآیندهای تثبیت شده است:
- ایجاد یک استاندارد کدنویسی: بر روی یک استاندارد کدنویسی جامع توافق کنید که شامل قراردادهای نام‌گذاری، قالب‌بندی، بهترین شیوه‌ها و ضدالگوهای رایج باشد. این استاندارد باید در اصول خود مستقل از زبان باشد اما در کاربرد خود برای هر زبان مورد استفاده، خاص باشد.
- استفاده از فرآیندهای بازبینی کد (Code Review): بازبینی‌های قوی کد ضروری هستند. بازخورد سازنده متمرکز بر خوانایی، قابلیت نگهداری و پایبندی به استانداردها را تشویق کنید. این یک فرصت عالی برای به اشتراک‌گذاری دانش و راهنمایی در سراسر تیم است.
- خودکارسازی بررسی‌ها: لینترها و قالب‌بندها را در خط لوله CI/CD خود ادغام کنید تا به طور خودکار استانداردهای کدنویسی را اعمال کنند. این امر ذهنیت‌گرایی را حذف کرده و سازگاری را تضمین می‌کند.
- سرمایه‌گذاری در آموزش و پرورش: جلسات آموزشی منظمی در مورد اصول کد تمیز و بهترین شیوه‌ها ارائه دهید. منابع، کتاب‌ها و مقالات را به اشتراک بگذارید.
- ترویج فرهنگ کیفیت: محیطی را پرورش دهید که در آن کیفیت کد توسط همه، از توسعه‌دهندگان تازه‌کار تا معماران ارشد، ارزشمند شمرده شود. توسعه‌دهندگان را تشویق کنید تا کد موجود را برای بهبود وضوح بازآرایی کنند.
- پذیرش برنامه‌نویسی دونفره (Pair Programming): برای بخش‌های حیاتی یا منطق پیچیده، برنامه‌نویسی دونفره می‌تواند به طور قابل توجهی کیفیت کد و انتقال دانش را بهبود بخشد، به ویژه در تیم‌های متنوع.
مزایای بلندمدت پیاده‌سازی خوانا
سرمایه‌گذاری زمان در نوشتن کد تمیز، مزایای بلندمدت قابل توجهی را به همراه دارد:
- کاهش هزینه‌های نگهداری: درک، اشکال‌زدایی و اصلاح کد خوانا آسان‌تر است که منجر به هزینه‌های نگهداری کمتر می‌شود.
- چرخه‌های توسعه سریع‌تر: وقتی کد واضح است، توسعه‌دهندگان می‌توانند ویژگی‌های جدید را پیاده‌سازی کرده و باگ‌ها را سریع‌تر برطرف کنند.
- بهبود همکاری: کد تمیز همکاری یکپارچه بین تیم‌های توزیع شده را تسهیل می‌کند و موانع ارتباطی را از بین می‌برد.
- بهبود فرآیند ورود اعضای جدید (Onboarding): اعضای جدید تیم می‌توانند با یک پایگاه کد با ساختار خوب و قابل درک، سریع‌تر به کار مسلط شوند.
- افزایش قابلیت اطمینان نرم‌افزار: پایبندی به اصول کد تمیز اغلب با باگ‌های کمتر و نرم‌افزار قوی‌تر همبستگی دارد.
- رضایت توسعه‌دهنده: کار با کد تمیز و سازمان‌یافته لذت‌بخش‌تر و کمتر خسته‌کننده است که منجر به روحیه و ماندگاری بالاتر توسعه‌دهندگان می‌شود.
نتیجه‌گیری
کد تمیز فراتر از مجموعه‌ای از قوانین است؛ این یک ذهنیت و تعهد به مهارت است. برای یک جامعه جهانی توسعه نرم‌افزار، پذیرش پیاده‌سازی خوانا یک عامل حیاتی در ساخت نرم‌افزارهای موفق، مقیاس‌پذیر و قابل نگهداری است. با تمرکز بر نام‌های معنادار، توابع مختصر، قالب‌بندی واضح، مدیریت خطای قوی و پایبندی به اصول اصلی طراحی، توسعه‌دهندگان در سراسر جهان می‌توانند به طور مؤثرتری با یکدیگر همکاری کرده و نرم‌افزاری ایجاد کنند که کار با آن برای خودشان و برای نسل‌های آینده توسعه‌دهندگان لذت‌بخش باشد.
همانطور که در سفر توسعه نرم‌افزار خود پیش می‌روید، به یاد داشته باشید که کدی که امروز می‌نویسید، فردا توسط شخص دیگری خوانده خواهد شد – شاید کسی در آن سوی کره زمین. آن را واضح کنید، آن را مختصر کنید، و آن را تمیز کنید.