-اصل 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

-اصل Explain Yourself in Code در کلین کد

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

// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) &&
      (employee.age > 65))

این کد بهتره یا اینکه جای کامنت این شرط رو توی تابع با اسم درست بزاریم ؟ مثل این

if (employee.isEligibleForFullBenefits())

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

#CleanCode
@CleverDevs - @CleverDevsGp

-اصل Use Pronounceable Names در کلین کد

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

ما برنامه نویسا باید اسم هارو جوری انتخاب کنیم که وقتی در بارش توضیح میدیم راحت باشیم مثلا این دوتا کد رو ببینید اولی اسم های غیر قابل تلفظ داره و دومی اسم های درست درمون

کد زیر :

class DtaRcd102 {
      private Date genymdhms;
      private Date modymdhms;
      private final String pszqint = "102";
};

میتونه با متغیر های بهتر زیر نوشته باشه :

class Customer {
      private Date generationTimestamp;
      private Date modificationTimestamp;
      private final String recordId = "102";
};

حالا وقتی میخوایم به رفیقمون بگیم بیا یه نگاه به این کد بنداز دیگه راحت تلفظ میکنیم و صدای احمقانه در نمیاریم


#CleanCode
@CleverDevs
@CleverDevsGp

-اصل Avoid Encoding در کلین کد


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

کاری میکنه که هر کس جدیدی تو تیممون عضو بشه مجبوره بشینه و یادبگیره که این رمزا چین و ...

اسم هایی که رمزگذاری شدن به ندرت قابل تلفظ هستن و این خودش اصل قبلی رو نقض میکنه


#CleanCode
@CleverDevs
@CleverDevsGp

-اصل Bad Comments در کلین کد

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

‏1 - Mumbling
یعنی اینکه کامنتی بزاری که نامفهمومه و بیشتر از اینکه بدرد بخور باشه باعث سر در گمیه

‏2 - Redundant Comments
یعنی کامنت هایی که بدرد نخور و اضافن و خوندوشون از خوندن کد کد زمان بیشتری میبره

‏3 - Misleading Comments
یعنی یجور لقمه رو دور سر بپیچونی که کسی که کامنت رو میخونه کلا فکر و ذهنش منحرف بشه به یه سمت دیگه

‏4 - Mandated Comments
کامنت هایی که برای هر متغیری مینویسد و معمولا زیاد بدرد نمیخورن مثل javadocs

‏5 - Journal Comments
اینکه بیای و تغییرات پروژه رو هر بار تو کامنتا بزنی ، اینکار برا قبل اومدن سیستم های کنترل ورژن مثل گیت بود این نوع کامنتا الان بدرد نمیخورن

‏6 - Noise Comments
کامنت هایی که کار خاصی ندارن و فقط کد رو شلوغ کردن مثل

/** The day of the month. */

private int dayOfMonth;

‏7 - Commented-Out Code
کامنت کردن کد ها هم یکی از بدترین نوع کامنت هاست

‏8 - Too Much Information
یعنی اینکه تو کامنت اطلاعات زیادی بدی انقدر زیاد باشه خوندنش کلی وقت ببره

این فصل هم تموم شد و میتونید لیستش رو اینجا ببینید

#CleanCode
@CleverDevs - @CleverDevsGp

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


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

Say What you mean , Mean what you say

#CleanCode
@CleverDevs - @CleverDevsGp

-اصل Use Searchable Names در کلین کد

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

البته اینم بگم که از متغیر های تک کلمه ای میشه تو اسکوپ های کوچیک استفاده کرد مثلا وقتی for loop میزنید منطقیه که از i یا j استفاده کنید.

#CleanCode
@CleverDevs
@CleverDevsGp

بجای اینکه از else if استفاده کنید (در بعضی شرایط) بهتره که از guard clauses استفاده کنید چون در این حالت کد خیلی خوانا تر و کوتاه تره.

#CleanCode Source
@CleverDevs
@CleverDevsGp

-اصل The Newspaper Metaphor در کلین کد

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

سورس کد هم تقریبا یه چیز مشابه به اینه شما با خوندن اسم فایل (یا حالا توی oop اسم کلاس) هدف کلی اون سورس فایل رو می فهمید قسمت های بالای کد که میتونه شامل توابع مهم یا متغیر ها و پراپرتی های مهم باشه (مثل پارگراف اول مقاله توی روزنامه) تا کسی که کد رو میخونه خلاصه ای از سورس دستش بیاد.

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

#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

Good 🆚 Bad Refactor

وقتی یه پروژه رو میخوایم ریفکتور کنیم چیکارا نکنیم که وضع بدتر شه؟ (این پارت یکه.)

1. Don't Change The Base

بیس کد فعلی رو تا حد امکان تغییر ندید، صرفا شرایط فعلی رو بهتر کنید. مثال:

قبل:

function processUsers(users: User[]) {
  const result = [];
  for (let i = 0; i < users.length; i++) {
    if (users[i].age >= 18) {
      const formattedUser = {
        name: users[i].name.toUpperCase(),
        age: users[i].age,
        isAdult: true
      };
      result.push(formattedUser);
    }
  }
  return result;
}

بعد از یه ریفکتور بد:

import * as R from 'ramda';
const processUsers = R.pipe(
  R.filter(R.propSatisfies(R.gte(R.__, 18), 'age')),
  R.map(R.applySpec({
    name: R.pipe(R.prop('name'), R.toUpper),
    age: R.prop('age'),
    isAdult: R.always(true)
  }))
);

بعد از یه ریفکتور خوب:

function processUsers(users: User[]): FormattedUser[] {
  return users
    .filter(user => user.age >= 18)
    .map(user => ({
      name: user.name.toUpperCase(),
      age: user.age,
      isAdult: true
    }));
}

توی ریفکتور اول بیس کد کلا تغییر کرد و از یه پکیج جدید استفاده شد و احتمال زیاد بقیه کسایی که تو پروژه هستن باهاش آشنایی ندارن و کار برای همه سخت میشه.

#CleanCode SRC
@CleverDevs @CleverDevsGp

-اصل Vertical Openness Between Concepts در کلین کد

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

import CleverDevs from telegram
function helloWorld(){
    console.log("hello world");
}
function sendStarRaction(){
    console.log('send star reaction on CleverDevs Posts');
}

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

import CleverDevs from telegram

function helloWorld(){
    console.log("hello world");
}

function sendStarRaction(){
    console.log('send star reaction on CleverDevs Posts');
}

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

#CleanCode
@CleverDevs - @CleverDevsGp

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

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

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

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


#CleanCode
@CleverDevs - @CleverDevsGp