-اصل Class Names در کلین کد

این اصل میگه که باید نام کلاس ها و آبجکت ها Noun (اسم) باشه مثل Customer , WikiPage , Account و از نام هایی مثل Manager , Processor , Data یا Info هم توی اسم کلاس ها استفاده نکنید . اسم کلاس نباید یک فعل باشه


#CleanCode
@CleverDevs
@CleverDevsGp

-اصل Method Names در کلین کد

این اصل میگه که نام متد ها باید فعل باشه مثل postPayment , deletePage , save و غیره و غیره

شما میتونید از get , set و is تو اسم متد هاتون استفاده کنید (اینا تو جاوا استاندارد هستن ولی خب تو بقیه زبون ها هم خوبه که استفاده کنید)

 
string name = employee.getName();
customer.setName("mike");
if (paycheck.isPosted())...

کد بالا مثال دقیقی از کلمات set ,get,is هستش که برای گرفتن از get برای ثبت کردن از set و برای چک کردن از is استفاده کرده

#CleanCode
@CleverDevs - @CleverDevsGp

-اصل Don't Be Cute در کلین کد


این اصل میگه موقع نامگذاری متغیر هات بامزه بازی در نیار
اگه اسم ها خیلی خفن باشن فقط کسایی که متوجهش میشن که حس شوخی نویسنده کد رو میدونن و همینا هم به سختی متوجه جوک میشن
ممکنه کسایی که کد رو میخونن بدونن HolyHandGrenade به چی اشاره میکنه. درسته اسم بامزه ایه ولی DeleteItems اسم بهتریه
همیشه واضح بودن رو به سرگرم کننده بودن ترجیح بدید
بامزگی توی کد اغلب کد رو به شکل عامیانه و محاوره ای نشون میده مثلا از whack به جای kill استفاده نکنید یا مثلا جوکی نزارید که تو وابسته به فرهنگی باشه مثلا از eatMyShorts به جای abort استفاده نکنید

Say What you mean , Mean what you say

#CleanCode
@CleverDevs - @CleverDevsGp

-اصل Pick one Word per Concept در کلین کد


این اصل میگه که شما برای هر مفهمومی باید تنها یک کلمه انتخاب کنید. مثلا اگه از fetch , retrive , get برای متد های معادل تو کلاس های مختلف استفاده کنیم گیج میشیم.

یا مثلا این گیچ کننده میشه که توی یه کد برای یه کار از متغیر هایی Manager , Controller , driver استفاده کنیم


#CleanCode
@CleverDevs - @CleverDevsGp

-اصل Don't Pun در کلین کد


این اصل میگه که از یک کلمه برای دوتا هدف مختلف استفاده نکن. اینکه از یک اصطلاح برای دوتا ایده مختلف استفاده کنی ایهام به وجود میاد


اگه اصل قبلی رو رعایت کرده باشید . شما در نهایت میتونید کلی کلاس داشته باشید که مثلا متد add رو دارن . تا موقعی که پارامتر ها و مقادیری که متد add برمیگردونه مثل هم باشن همه چی اوکیه.


یا ممکنه شما از کلمه add به جای ثبات (consistency) استفاده کنید اما اونی که کد شمارو میخونه همچین حسی نداره. بزارید یه مثال بزنم فک کنید ما چنتا کلاس داریم که همشون یه متد add دارن و این متد میاد یه محصول جدید به دیتابیس اضافه میکنه حالا اگه بخوایم تو یه کلاس دیگه یه متدی داشته باشیم که بیاد یه مقداری رو به یه ارایه ای اضافه کنه منطقیه که اسمش رو بزاریم add ؟؟ طبعا نه چون کلی متد add داریم که کار متفاوتی دارن اینجور موقع میتونیم بجاش از insert یا append استفاده کنیم


خلاصه اینکه هدف ما به عنوان نویسنده اینه که کد رو به ساده ترین شکل ممکن که میشه فهمید بنویسیم


#CleanCode
@CleverDevs - @CleverDevsGp

-اصل Solution Domin Names در کلین کد

این اصل میگه که حواستون باشه کسی که کد شمارو میخونه برنامه نویسه پس از اصطلاحات کامپیوتری برای اسماتون استفاده کنید و خب این عاقلانه نیست که بیایم از اصطلاحات اشتباه (خارج از کامپیوتر) استفاده کنیم


اصل Use Problem Domain Names هم میگه که وقتی هیچ برنامه نوییییییسی نیست که کاری که میکنید رو بخواد میتونید از دامنه اصطلاحات مشکل استفاده کنید در نهایت یه نفر که میخواد کدتون رو  نگهداری کنه از یه متخصص دامنه معنی اینارو میپرسه


ولی فارغ از همه چرندیات بالا فقط اینو بدونید که بهتره تو متغیر هاتون از اصطلاحات کامپیوتری استفاده کنید

#CleanCode
@CleverDevs - @CleverDevsGp

-اصل Add Meaningful Context در کلین کد

این اصل میگه که کلا تعداد کمی نام داریم که به خودی خود معنی داشته باشند . بیشتر نام ها ندارن بجاش شما باید نام هاتون برای خواننده یجوری با محصور کردن توی کلاس ها و توابعی که خوب نامگذاری شدن قرار بدید و وقتی که همه کارایی که کردین جواب نداد مجبورید که از پیشوند ها استفاده کنید

اگه متوجه نشدی به این مثال دقت کن : فک کنید شما این چنتا متغیر رو دارید firstName , lastName , street , houseNumber , city , state and zipcode این که اینا باهم اومدن معلومه که مربوط به آدرس هستن ولی اگه شما متغیر state رو تنها میدیدن میفهیدید که مربوط به ادرسه ؟؟


شما میتونید با اضافه کردن پیشوند یه زمینه ای به خواننده بدید مثلا وقتی نام های addrFirstName, addrLastName, addrState, رو ببینه میفهمه اینا یه بخش از یه ساختار بزرگتر هستن


البته یه راه حل بهتر اینه که یه کلاس Address بسازیم و پارامتر هارو توش تعریف کنیم حالا دیگه IDE یا کامپایلر هم میدونه که اینا مربوط به آدرسن


// برای اینکه طولانی نشه بقیه این پست رو میذارم تو کامنتا

#CleanCode
@CleverDevs - @CleverDevsGp

-اصل Don't Add Gratuitous Context در کلین کد

این اصل میگه که چیزای چرت و بیهوده به متغیر هات اضافه نکن

مثلا فرض کنید یه برنامه داریم به اسم "Gas Station Deluxe" اینکه بیایم اول همه کلاس ها و فانکشن ها متغیر ها پیشوند GSD رو بنویسیم وقتی که تو IDE مینویسی G میاد برات کل متغیر هارو پیشنهاد میده و حتی تاثیر منفی داره رو سرعت کد زدنت


در کل نام های کوتاه تر بهتر از نام های بلند تره و نباید برای هر نام چیزی بیشتر از اون چه که نیازه اضافه کنید

ـــــــــــــــــــــــــــــــــــــــــــــــــــــــ

اما سخن آخر اینکه چپتر دوم که در باره انتخاب نام های معنادار بود تموم شد و میتونید لیستش رو اینجا ببینید
اگه دوست دارید در باره فصل های بعدی هم پست هارو ادامه بدم رو این پست ریکشن برید ❤️🔥

#CleanCode
@CleverDevs - @CleverDevsGp

-اصل Small در کلین کد

این اصل میگه که اولین قانون توی فانکشنا اینه که باید کوچیک باشن
بر اساس نویسنده کتاب اجبار خاصی نیست که توابع کوچیک باشن اما بر اساس تجربه توابع کوچیک تر خیلی بهترن


قدیما میگفتن که تابع نباید بزرگتر از اسکرین (صفحه) باشه اما اون برا وقتی بود که مانیتور ها کلا 20 خط جا داشتن و هر خط تعداد کاراکتر کمتر از الان اما الان به لطف مانیتور های بزرگتر و فونت های کوچیک تر هر اسکرین میتونه بالای 100 خط کد بگیره و هر خط هم بیشتر از 150 کاراکتر پس اگه به این قانون بسنده کنیم اجازه داریم تابع 100 خطی بنویسیم که زیادی بزرگه پس اینم کنسله


خلاصه این اصل هم اینه که هرچی توابعتون کوچیک تر باشه کدتون تمیز تره راحت تر میتونید دیباگ کنید و ....

#CleanCode
@CleverDevs - @CleverDevsGp

-اصل Do One Thing در کلین کد

این اصل میگه هر تابعی باید فقط یه کار انجام بده و اگه نیاز به دوتا کار شد باید دوتا فانکشن بکنیش

FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL THEY SHOULD DO IT ONLY.

اگه یک تابع فقط مراحلی رو انجام میده که به اسمش میخوره یعنی فقط یک کار میکنه و کارت درسته


#CleanCode
@CleverDevs - @CleverDevsGp

-اصل One Level of Abstraction per Function در کلین کد

برای اینکه مطمئن بشیم تابع ما یک کار انجام میده باید مطئمن بشیم که کد های توی تابع یک سطح انتزاع رو داشته باشن برای اینکه از حالت گنگ بودن در بیاد به این مثال دقت کنید

فک کن شما یه تابع (کدش رو تو کامنتا میفرستم ) دارید بعد یه تیکه از کدتون سطح بالاس مثل getHtml() یه تیکه از کدتون مثل PathParser.render سطح متوسطه و یه تیکه دیگه مث append سطح پایین
در واقع این کد اصل Do One Thing رو اصلا رعایت نکرده

ترکیب کردن لول های مختلف انتزاع باهم توی تابع همیشه باعث گیج شدن ما میشه


#CleanCode
@CleverDevs - @CleverDevsGp

-اصل Switch Statements در کلین کد

این اصل میگه که کوچیک کردن Switch ها سخته و حتی اونایی که 2 تا case دارن هم تا حدی بزرگ محسوب میشن یسری جاها هم ما مجبوریم ازشون استفاده کنیم برای رفع این مشکل میتونیم از پلی مورفیسم (Polymorphism) استفاده کنیم مثلا کد زیر رو در نظر بگیرید

public Money calculatePay(Employee e)
throws InvalidEmployeeType {
    switch (e.type) {
        case COMMISSIONED:
            return calculateCommissionedPay(e);
        case HOURLY:
            return calculateHourlyPay(e);
        case SALARIED:
            return calculateSalariedPay(e);
        default:
            throw new InvalidEmployeeType(e.type);
    }
}

این کد یه سری مشکلات داره :

اول اینکه بزرگه
دوم اینکه بیشتر از یه کار انجام میده
سوم اینکه اصل اول SOLID رو نقض میکنه چون بیشتر از یه دلیل برای تغییر دادنش دارید
چهارم اینکه اصل دوم SOLID رو هم نقض میکنه چون هربار که type جدید اضافه میشه باید تغییر کنه
اما مشکل اصلی اینه که این ساختار ممکنه تو هزارتا فانکشن دیگه هم نیاز بشه

اما چطور حلش کنیم ؟ (کد توی کامنت رو ببینید ) باید ساختار Switch رو توی یک ABSTRACT FACTORY بزاریم تا بیاد از روی switch برامون گزینه های مناسب مشتقات Employee رو بسازه و توابع مختلف مث calculatePay , isPayDay و deliverPay به صورت پلی مورفیسی از طریق اینترفیس Employee وصل بشن بهش

یعنی ما برای راحت شدن از دست سویچا کاری میکنیم که یه بار بنویسیمشون و چند جا استفاده کنیم


پی نوشت : این اصل کمی طولانی بود و سخت بود توی یه پست توضیحش داد از طرفی توی مثال هاش از شی گرایی اونم توی جاوا استفاده کرده و کارمون تا حدودی سخت تر شد برا همین ممکنه یکم گنگ و سخت شده باشه همین که سعی کنید از سوییچ کمتر استفاده کنید و بتونید کدی بنویسید که از یه سوییچ چند بار استفاده کنید کافیه

#CleanCode
@CleverDevs - @CleverDevsGp

-اصل Function Arguments در کلین کد

این اصل میگه ایده آل ترین تعداد آرگومان برای یک تابع صفره حالا صفر نشد یدونه آرگومان داشته باشه و اگه مجبور بودید دوتاش تاش بکنید ته تهش سه تا آرگومان یه تابع بیشتر از سه تا آرگومان نباید داشته باشه مگر در شرایطی خاص!

زیاد شدن آرگومان ها برای تست نوشتن هم دردسره فک کن بخوای کلی تست بنویسی تا همه نوع آرگومانی تست بشن و برنامه بدون مشکل باشه . حالا اگه ارگومانی نداشته باشی کارت اسونه یکی داشته باشی یکم سخت تر میشه و به همین ترتیب هرچی ارگومان ها بیشتر باشن کار تست نویسی هم سخت تر میشه


#CleanCode
@CleverDevs - @CleverDevsGp

-اصل Have No Side Effects در کلین کد


این اصل میگه که تابع شما باید یه کار انجام بده اما حواستون باشه که تاثیرات جانبی روی برنامه نداشته باشه که یهو به باگ بخورین و نفهمید از کجا خوردید

مثلا این کد که میاد و یوزر نیم و پسورد رو چک میکنه و اگه اوکی بود true و اگه مشکلی بود false برمیگردونه رو در نظر بگیرید

public class UserValidator {
    private Cryptographer cryptographer;

    public boolean checkPassword(String userName, String password) {
        User user = UserGateway.findByName(userName);
        if (user != User.NULL) {
            String codedPhrase = user.getPhraseEncodedByPassword();
            String phrase = cryptographer.decrypt(codedPhrase, password);
            if ("Valid Password".equals(phrase)) {
                Session.initialize();
                return true;
            }
        }
        return false;
    }
}

این کد ظاهرا اوکیه اما دقت کنید یه قسمت Session.initialize داره که خب از اسم تابع معلوم نیس قراره سشنی درست بشه و خب کسی که کد رو میخونه نمیدونه ریسک پاک شدن سشن فعلی هست


ولی اگه نیازه که اون Session.initialize اونجا باشه بهتره که توی اسم تابع هم بیاد و خواننده کد از اسم تابع بفهمه که اونجا یه سشن initialize میشه و از side effect جلوگیری کنه


لپ کلام اینکه حواستون باشه علاوه بر اینکه تابع یه کار انجام میده در چنین شرایطی باید قسمت های مهم تابع از اسمش معلوم باشه تا تاثیرات جانبی نداشته باشه

#CleanCode
@CleverDevs - @CleverDevsGp

-اصل Command Query Separation در کلین کد

این اصل میگه تابع شما یا باید کاری انجام بده یه به سوالی جواب بده اگه هردوتاش رو میکنه بدون که اشتباه میزنی مثلا یه تابع باید یه چیزی رو تو ابجکتی تغییر بده یا یه اطلاعاتی بگیره ازش اگه جفت کار هارو بکنه یکم گیج کننده میشه

مثلا این مثال رو در نظر بگیرید

public boolean set(String attribute, String value);

این کد میاد به یه اتریبیوتی مقداری رو ست میکنه و اگه موفقیت امیز بود ture بر میگردونه و اگه مشکل داشت false میده حالا اگه بیایم اینو توی شرط استفاده کنیم

if (set("username", "CleverDevs"))...

از نگاه خواننده کد ببینید : «این الان چک میکنه که یوزر نیم unclebob از قبل ست شده یا داره چک میکنه »

کلمه set یه فعله ولی وقتی توی شرط استفاده شده قید بنظر میاد و باعث نامفهموم شدن کد میشه
میتونیم به جای set از setAndCheckIfExists استفاده کنیم اما بازم ممکنه برای if statement جالب نباشه بهترین کار اینه که یچیزی مث کد زیر بزنیم :

if (attributeExists("username")) {
      setAttribute("username", "CleverDevs");
       x...
}

خلاصه این اصل این بود که تابعتون نباید هم کاری انجام بده هم چیزی بر گردونه

#CleanCode
@CleverDevs - @CleverDevsGp