رابرٹ مارٹن، کلین کوڈ۔ ڈویلپرز کے لیے "کنگ فو کوڈ" پر کتاب کا جائزہ

ہیلو جاوراشیوائٹس! یہ مضمون رابرٹ مارٹن کی کتاب "کلین کوڈ" کا جائزہ ہے۔ ہم مل کر آپ کے کوڈ کو بہتر اور بہتر بنانے کے طریقے دیکھیں گے، اور آخر میں ایک چھوٹا لیکن دلچسپ کام آپ کا منتظر ہے۔ ہر روز، جب ہم آپ کا کوڈ ایڈیٹر کھولتے ہیں، تو ہمیں کئی کلاسز، فنکشنز اور متغیرات کا سامنا کرنا پڑتا ہے۔ بہترین آپشن یہ ہے کہ اگر یہ آپ کا کوڈ ہے جو شروع سے لکھا گیا ہے، ایک بار لکھا گیا ہے، اس میں چند سطریں ہیں، آپ اکیلے اس پر کام کر رہے ہیں، اس میں کوئی ترمیم نہیں ہے اور گاہک کی طرف سے مزید تعاون نہیں ہے۔ لیکن! جیسا کہ پریکٹس سے پتہ چلتا ہے، ہاں، مجھے لگتا ہے کہ آپ خود سمجھتے ہیں کہ ایسا نہیں ہوتا۔ بنیادی طور پر، ہمیں کسی نہ کسی طرح اپنی ٹیم کے اراکین کے ساتھ بات چیت کرنی ہوگی، "ہندو" کوڈ کو برقرار رکھنا ہوگا، اور مصنوعات کو لاکھوں لائنوں میں پارس کرنا ہوگا۔ میں نے اکثر اپنے تربیتی ساتھیوں سے اس طرح کے جوابات سنے ہیں: "یہ کوڈ میں نے لکھا تھا، اور میں اسے کسی کو دکھانے والا نہیں ہوں،" لیکن جب میں ایسے کوڈ کے ساتھ مدد کے لیے مدد پر درخواستیں دیکھتا ہوں، تو اس میں کافی وقت لگتا ہے۔ وقت (بعض اوقات واقعی ایک لمبا وقت) اس بات کو سمجھنے اور سمجھنے کے لیے کہ وہ شخص مجھے کیا بتانا چاہتا تھا، میں یہاں تک کہ "مٹا کر دوبارہ لکھنا" کہنا چاہتا ہوں! ان لوگوں کے وقت اور توانائی کی تعریف کریں جو آپ کی مدد کرنا چاہتے ہیں، صحیح لکھیں، اور اگر آپ نہیں جانتے کہ کیسے، سیکھنے میں کبھی دیر نہیں ہوتی۔ رابرٹ مارٹن کی کتاب اس فارمیٹ کی کتابوں میں اس لیے نمایاں ہے کہ اس میں جاوا میں بہت سی مثالیں ہیں۔ یہ میری طرف سے تھوڑا سا جنونی بیان ہوسکتا ہے، لیکن یہ OOP انداز میں لکھا گیا تھا، یعنی حصوں اور حصوں کی تحریر میں۔ سمجھنے اور پڑھنے میں آسان، کتاب کو چلتے پھرتے یا شام کو سونے سے پہلے پڑھنا آسان ہے۔ کلین کوڈ کو 3 حصوں میں تقسیم کیا گیا ہے۔ پہلے حصے میں، ہم سے کہا گیا ہے کہ کتاب کی تھیوری کو دیکھیں، ڈیزائن کے نمونوں اور اچھے اخلاق کے اصولوں کے بارے میں جانیں۔ دوسرا حصہ ہمیں ری فیکٹرنگ اور لکھنے کی مشق کرنے کی دعوت دیتا ہے، اور تیسرا حصہ مثالوں میں کوڈ "smells" کا حتمی خلاصہ ہے۔ ٹھیک ہے، مصنف نے بہت سے عنوانات کو چھو لیا ہے جن کے لیے آپ کو بنیادی طور پر جاوا کور کے علم کی ضرورت ہوگی، لیکن JUnit یونٹ ٹیسٹ، Log4j لاگنگ، ڈیزائن کے آسان ترین نمونوں کا علم کے لیے مخصوص حصے بھی موجود ہیں (لیکن جیسا کہ میں نے اوپر کہا، وہاں موجود نہیں ہیں۔ ان میں سے بہت سے، اور ناقابل فہم ہر چیز کو کامیابی سے گوگل کیا جا سکتا ہے، ہاں اور جاوا رش کورس میں اس کا تجزیہ)۔ کتاب کے تمام ابواب ایک دوسرے سے متعلق نہیں ہیں؛ آپ اپنی پسند کے باب سے کامیابی کے ساتھ پڑھنا شروع کر سکتے ہیں۔ مرکزی خیالات کا ایک مختصر خلاصہ جو میں نے کتاب سے اٹھایا ہے۔ میں ان پر آپ کے تبصروں کا مشکور ہوں گا، جس میں آپ ان بیانات کے بارے میں اپنا نقطہ نظر شیئر کر سکتے ہیں۔

1. تبصرے == برائی۔

زیادہ تر معاملات میں، تبصرے بیساکھی ہوتے ہیں جن سے ہم اپنے برے کوڈ کو چھپانے کی کوشش کرتے ہیں۔ اور بعض صورتوں میں، وہ طریقوں یا متغیرات کے مقصد کے بارے میں بھی جھوٹ بولتے ہیں اگر مسلسل کوڈ ری فیکٹرنگ ہو رہی ہے۔

2. تبصرہ کردہ کوڈ، ڈیڈ کوڈ۔

کوڈ کے ان ٹکڑوں کو اپنی درخواست میں چھوڑنا کوڑا کرکٹ کے مترادف ہے۔ غیر استعمال شدہ کوڈ وقت کے ساتھ جمع ہوتا ہے اور آپ کی درخواست کی صفائی میں مداخلت کرتا ہے، ایسے ماڈیولز کے کوڈ کو وقتاً فوقتاً چیک کریں۔

3. طریقوں، کلاسز اور متغیرات کے عنوانات۔

اس موضوع پر بحث کرنے کے لیے الگ الگ مضامین کی ضرورت ہے۔ سستی نہ کریں اور ایسے نام لکھیں جو ان کے مقصد کے بارے میں بتا سکیں۔ ہجے کے عنوانات میں کچھ معیارات سیکھیں۔ تفصیلی مطالعہ کے لیے یہ موضوع "لازمی ہونا چاہیے" ہے۔

4. ہر طریقہ اور متغیر کی کلاس کے درجہ بندی میں اپنی جگہ ہے۔

عام طور پر، ایک کلاس میں متغیرات اور طریقے (جامد اور غیر جامد)، ایک کنسٹرکٹر، نیسٹڈ اور اندرونی کلاسز، اور enums ہو سکتے ہیں۔ مختصراً، بہت ساری معلومات ہیں، اور کلاس میں ہر ایک کی جگہ کا تعین کرنا ضروری ہے۔ اگر آپ جاوا کور کلاسز کو دیکھیں تو آپ دیکھیں گے کہ ساخت واضح طور پر ترتیب دی گئی ہے، ہم ہر حصے کو اس کی جگہ پر دیکھ سکتے ہیں، یقیناً آپ کے پروجیکٹس میں یہ پروجیکٹ کے اندر تبدیل ہوسکتا ہے، لیکن ہر کلاس میں نہیں۔ اپنے لیے، میں نے مندرجہ ذیل تعمیراتی ڈھانچے کی وضاحت کی ہے: کلاس کے آغاز میں میرے پاس جامد متغیرات ہیں، پھر آبجیکٹ متغیرات + Enums اگر وہ موجود ہیں۔ متغیرات کے بعد، میں کلاس کنسٹرکٹرز کی وضاحت کرتا ہوں۔ پھر میں کلاس کے ساتھ کام کرنے کے طریقے لکھتا ہوں۔ طریقوں کے بعد میں گیٹرز اور سیٹٹرز لکھتا ہوں۔ اور آخر میں میری اندرونی کلاسیں ہیں۔ آپ میرا ڈھانچہ استعمال کر سکتے ہیں یا کمنٹس میں اپنا لکھ سکتے ہیں۔

5. طریقوں کے تجرید کی سطح۔

میرے لیے یہ دریافت نمبر 1 تھی۔ ہر طریقہ تجرید کی صرف ایک سطح پر آپریٹرز پر مشتمل ہے۔ آپ کو ملٹی لیول آپریشنز کو ایک ساتھ نہیں ملانا چاہیے۔

6. نقص کو ہینڈل کرنا۔

چیک شدہ یا غیر چیک شدہ استثناء، جو پروجیکٹ میں استعمال کرنا بہتر ہے (آپ کا کیا خیال ہے؟، تبصرے لکھیں)؟ میں چیک شدہ کا حامی ہوں، لیکن کتاب غیر چیک شدہ استثناء کو باہر سے دیکھنے میں مدد کرتی ہے۔ درحقیقت، غیر چیک شدہ استثناء طریقہ دستخط کو بگاڑ نہیں دیتا، خاص طور پر اس بات پر غور کرتے ہوئے کہ استثناء ایک ساتھ کئی تہوں کو "چھید" دیتا ہے۔ سب سے چھوٹی تبدیلی کی تکلیف اسے پکڑنے سے پہلے طریقوں کی پوری زنجیر کی دوبارہ تعریف کی طرف لے جاتی ہے، جو بہت سے معاملات میں ترقی کے لیے انتہائی تکلیف دہ ہے۔

7. کوڈ فارمیٹنگ۔

مناسب طریقے سے فارمیٹ شدہ کوڈ نہ صرف واضح ہے، بلکہ انتہائی پڑھنے کے قابل بھی ہے۔ آپ کو بریکٹ اور اندر کے اعمال کا فوراً اندازہ ہو جاتا ہے۔ اگر، ورنہ تعمیرات میں حالات کی مثال کا استعمال کرتے ہوئے، آپ کو سب کچھ ایک لائن میں نہیں لکھنا چاہئے، لمبی زنجیریں منتقل کرنا بہتر ہے۔

8. حالت میں نفی۔

حالات میں انکار سے بچنے کی کوشش کریں، یہ زیادہ نفسیاتی عنصر ہے، ہمارا دماغ انکار کو اچھی طرح نہیں سمجھتا، اور ہاں! اس سے پہلے کہ اظہار نظر نہ آئے۔ مثال کے طور پر، اگر (!condition.isTrue) طریقہ کو دوبارہ لکھنا بہتر ہے تو اس کی نفی کرنا، یہ اس طرح بہت آسان بنا دے گا (condition.isFalse)

9. افعال کو ایک آپریشن کرنا چاہیے۔

اگر آپ کا طریقہ بہت سے آپریشن کرتا ہے، تو انہیں واحد آپریشن کے طریقوں میں تقسیم کریں۔ یہ طریقے سپورٹ کرنے میں بہت آسان، جانچنے میں آسان، اور اگر ضروری ہو تو تبدیل یا ہٹا دیے جاتے ہیں۔

10. اپنے آپ کو نہ دہرائیں۔

DRY کوڈ کو نہ دہرائیں (اپنے آپ کو نہ دہرائیں)۔ یہ ان بنیادی اصولوں میں سے ایک ہے جو آپ کے کوڈ کو نمایاں طور پر کم کر دے گا، اسے ذہن میں رکھیں۔ اپنے بار بار کوڈ کے تمام ٹکڑوں کو ایک الگ فنکشن میں ڈالنے کی کوشش کریں۔ بلاشبہ، ہم DRY، KISS (اسے سادہ بیوقوف رکھیں)، SOLID ، YAGNI کے بارے میں بہت زیادہ بات کر سکتے ہیں۔ یہ شرائط سمجھنے اور ڈیزائن کے لیے ضروری ہیں۔ وہ ایک الگ مضمون کے قابل ہیں، شاید میں ان کے بارے میں دوبارہ لکھوں گا، کیونکہ یہ مضمون کتاب "کلین کوڈ" کے جائزے کے لیے وقف ہے۔ جیسا کہ وعدہ کیا گیا ہے، آپ کے لیے ایک چھوٹا اور آسان کام۔ پروگرام کو دیے گئے ڈیٹا کی بنیاد پر موٹاپا انڈیکس کا حساب لگانا چاہیے۔ کوڈ میں غلطیوں اور اصلاحات کی تعداد کمنٹس میں لکھیں۔ پی ایس کوڈ کام کر رہا ہے اور اگر صحیح طریقے سے استعمال کیا جائے تو اپنا کام انجام دیتا ہے۔

//Weight in kg.
//Height in metres.
public class sample {
    public static void main (String[] args) {
        humanIMB humanIMB = new humanIMB(80,1.52);
        System.out.println(humanIMB.Result());
    }
}
class humanIMB {
    public double W; //Weight Human
    public double H; // Height Human
    private static double imb;
    public humanIMB(double w, double h) {
        W = w;
        H = h;
        imb = W / (H * H);
    }
    public double takeW() {
        return W;
    }
    public void putW(double w) {
        W = w;
        imb = W / (H * H);
    }
    public double takeH() {
        return H;
    }
    public void putH(double h) {
        H = h;
        imb = W / (H * H);
    }
    public static double takeImt() {
        return imb;
    }
    public static String Result() {
        String  string = null;
        if (imb >=18.5 & imb <25) {
            string ="Норма, ты в форме!";
        }
        if (imb >=25 & imb <30) {
            string ="Предожирение. Эй, поосторожнее с пирожными ";
        }
        if (imb >=30) {
            string ="Ожирение. SCHWEINE! Хватит жрать, иди на треню!";
        }
        if (imb <18.5) {
            string ="Дефицит массы тела. В модели решил переквалифицироваться?";
        }
        return string;
    }
}