انٹیلی جے آئیڈیا: کوڈ اسٹائل اور فارمیٹنگ

جدید آلات ترقی کے عمل کو آسان بناتے ہیں۔ خاص طور پر، آپ کے کوڈ کے انداز کی نگرانی کرنا آسان ہے، اس کی "غیر مجاز" فارمیٹنگ کو کم سے کم کرنے کی کوشش کرنا۔ اس جائزے میں، میں اپنے آپ کو ان ٹولز سے واقف کرنے کی تجویز کرتا ہوں جو IntelliJ Idea IDE ڈویلپر کو کوڈ کو پڑھنے میں خوشگوار اور سمجھنے میں آسان بنانے کے لیے فراہم کرتا ہے۔

تعارف

ایک پروگرامنگ زبان اس زبان سے بہت ملتی جلتی ہے جو لوگ بولتے ہیں۔ فرق صرف اتنا ہے کہ یہ ایک خاص زبان ہے جو شروع میں کمپیوٹر سے بات چیت کے لیے استعمال ہوتی ہے تاکہ اسے سمجھا جا سکے کہ ہم اس سے کیا چاہتے ہیں۔ لیکن کمپیوٹر کے ساتھ آپس میں کوئی بات چیت نہیں ہو سکتی۔ یہاں تک کہ جب آپ نے پروگرامنگ لینگویج سیکھنا شروع کی تو آپ نے کسی کتاب یا جاوا رش جیسے کچھ تعلیمی وسائل کو دیکھا۔ اور اس سورس میں آپ نے کوڈ دیکھا جسے کمپیوٹر سمجھ لے گا۔ لیکن آپ کو یہ بھی سمجھنا چاہیے کیونکہ آپ جاوا زبان کا علم حاصل کرتے ہیں۔ کسی بھی زبان کی طرح، کوڈ بنانے کے لیے پروگرامنگ کے کچھ اصول ہوتے ہیں۔ مثال کے طور پر، شائستہ معاشرے میں باڑ کے ساتھ لکھنا برا آداب سمجھا جاتا ہے، اور جاوا میں بڑے حرف کے ساتھ کسی طریقہ کو کال کرنا کوڈ کے انداز کی سراسر خلاف ورزی ہے۔ جاوا کوڈ کو فارمیٹ کرنے کے قوانین جاوا کوڈ کنونشن دستاویز میں وضع کیے گئے ہیں ۔ اس کے علاوہ، کوڈ کا انداز چھوٹی تفصیلات کو منظم کر سکتا ہے، جیسے انڈینٹیشن۔ اور جب ورژن کنٹرول ٹولز استعمال کیے جاتے ہیں، تو پورے ڈراؤنے خواب کا تصور کریں جب ہر کوئی ایک فائل کو ٹیب کے طور پر یا اسپیس کے طور پر انڈینٹ میں محفوظ کرتا ہے۔ کسی ایسے شخص کے لیے یہ کیسا ہوگا جسے صرف ایک طریقہ میں ترمیم کی جانچ پڑتال کرنے کی ضرورت ہے، لیکن ٹیبز میں خالی جگہوں کی درستگی کی وجہ سے یا اس کے برعکس پوری فائل بدل جائے گی۔ قدرتی طور پر، عام زبان کی طرح، اسلوب اس بات پر منحصر ہو سکتا ہے کہ اسے کہاں استعمال کیا جاتا ہے۔ مثال کے طور پر، انٹرنیٹ پر آپ گوگل جاوا اسٹائل گائیڈ یا ٹویٹر جاوا اسٹائل گائیڈ تلاش کرسکتے ہیں ۔ اس جائزے کے مضمون کے لیے، ہمیں ایک امتحانی مضمون کی ضرورت ہوگی۔ آئیے گریڈل پروجیکٹ بلڈ سسٹم کی سروس استعمال کریں۔ یہ ہمیں فوری آغاز کے لیے ٹیمپلیٹ کا استعمال کرتے ہوئے ایک نیا پروجیکٹ بنانے کی اجازت دے گا۔ گریڈل کے پاس بہت اچھا پلگ ان ہے: Init پلگ ان بنائیں ۔ آئیے نئی ڈائرکٹری میں جائیں اور وہاں کمانڈ پر عمل کریں: gradle init --type java-application اس کے بعد، IntelliJ Idea لانچ کریں۔ اگر آپ کو پہلے سے کھلے پروجیکٹ کے ساتھ ونڈو نظر آتی ہے (آپ کو کوڈ ایڈیٹر، پروجیکٹ ڈھانچہ کا درخت نظر آئے گا)، استعمال کرکے اس پروجیکٹ کو بند کریں File -< Close Project۔ اب ویلکم ونڈو میں ہم "Import Project"اپنے نئے پروجیکٹ کو عمل میں لائیں گے اور درآمد کریں گے۔ درآمد کرتے وقت، جھنڈا سیٹ کریں "Use autoimport"۔ آئیے اندازہ لگاتے ہیں کہ کیا جدید ترقیاتی آلات کی مدد سے زندگی کو آسان بنانا ممکن ہے۔

آئیڈیا میں فارمیٹنگ کوڈ

پروجیکٹ کو درآمد کرنے کے بعد، کلید کا مجموعہ دبائیں Ctrl+Nاور کلاس میں جائیں AppTest۔ یہ کلاس ڈیفالٹ ٹیسٹ کلاس ہے۔ ایسا لگتا ہے:

import org.junit.Test;
import static org.junit.Assert.*;

public class AppTest {
    @Test public void testAppHasAGreeting() {
        App classUnderTest = new App();
        assertNotNull("app should have a greeting", classUnderTest.getGreeting());
    }
}

یہاں فوری طور پر آپ کی نظر کیا پکڑتی ہے؟ ایک لائن پر طریقہ کے اعلان کے ساتھ ایک تشریح، جو بدصورت نظر آتی ہے، متفق ہوں۔ اسے کیسے ٹھیک کیا جائے؟ IntelliJ Idea میں "Code"مختلف کوڈ ہیرا پھیری کے لیے ایک مینو سیکشن ہے۔ ایسی ہیرا پھیری میں سے ایک "Reformat Code"کلیدی امتزاج ہے Ctrl + L۔ درخواست کے بعد، تشریح ایک لائن پر ہوگی، اور طریقہ خود دوسری لائن پر ہوگا۔ یہ فوری طور پر قابل غور ہے کہ یہ آپریشن کوڈ کے منتخب حصے پر کیا جاتا ہے ۔ اور اگر ایسی کوئی چیز نہیں ہے تو، فارمیٹنگ آپریشن تمام مواد پر کیا جائے گا۔ آئیے اب ایک نیا ٹیسٹ طریقہ شامل کریں:

@Test
public void testSummOfOddNumbers() {
	List<Integer> data = Arrays.asList(1, 4, 2, 3, 6, 7, 9);
	Integer result = data.stream().filter(number -> number % 2 == 0).reduce((n1, n2) -> n1 + n2).get();
	assertThat(result, is(12));
}

اور دو درآمدات:

import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;

جیسا کہ آپ دیکھ سکتے ہیں، سٹریم پر آپریشن ایک لائن پر رکھا گیا ہے۔ لیکن کیا ہوگا اگر ہم اس بات کو یقینی بنانا چاہتے ہیں کہ وہ طریقے جن کی کالز زنجیروں میں جکڑی ہوئی ہیں ہمیشہ ایک نقطہ پر نئی لائنوں میں تقسیم ہوں؟ ایک طرف، ہم یہ دستی طور پر کر سکتے ہیں۔ لیکن یاد رکھیں کہ ہم چاہتے ہیں کہ ہر چیز ہمارے لیے کام کرے۔ سب کے بعد، وقت وقت پر ہم بھول جائیں گے، اور کوڈ کی شکل ہر جگہ مختلف ہو جائے گی، اور یہ اچھا نہیں ہے. یہ پتہ چلتا ہے کہ آپ کو اس اصول میں ترمیم کرنے کی ضرورت ہے جس کے ذریعے Idea فارمیٹنگ انجام دیتا ہے۔ مینو میں آئیڈیا آئٹم کو منتخب کریں File -> Settings(یا کلک کریں Ctrl + Alt + S)۔ سیٹنگز ونڈو میں سرچ فیلڈ میں "کوڈ اسٹائل" لکھیں۔ کوڈ اسٹائل سیکشن میں نہ صرف جاوا کے لیے سیٹنگز بتانا ممکن ہے۔ لیکن اب ہم جاوا میں دلچسپی رکھتے ہیں۔ جیسا کہ آپ دیکھ سکتے ہیں، ترتیبات کو کئی ٹیبز میں تقسیم کیا گیا ہے۔ سب سے زیادہ مفید یہ ہے کہ تبدیلی کا نتیجہ ونڈو کے دائیں جانب ایک مثال میں دکھایا جائے گا: جیسا کہ آپ اسکرین شاٹ میں دیکھ سکتے ہیں، ہم "زنجیروں سے بند میتھڈ کالز" کی ترتیب کو "لپٹیں ہمیشہ" کے طور پر بتا سکتے ہیں، یعنی ضم شدہ طریقہ کالوں کے لیے ہمیشہ تقسیم کریں۔ اب آئیے ٹیسٹ میں فارمیٹنگ کو دوبارہ دبائیں اور دیکھیں کہ یہ واقعی کام کرتا ہے! لیکن بعض اوقات ایسا ہوتا ہے کہ فارمیٹنگ کے عمومی اصولوں سے ہٹ کر کچھ کوڈ فارمیٹ کرنے کی ضرورت ہوتی ہے۔ آئیے مندرجہ ذیل فارمیٹنگ کو ترتیب دیں: فارمیٹنگ کو غیر فعال کرنے کے لیے، کوڈ اسٹائل سیکشن میں غیر فعال فارمیٹنگ مارکر کے لیے سپورٹ کو فعال کرنا ضروری ہے: اب ہم اپنے ٹیسٹ کے کوڈ کو تبدیل کر سکتے ہیں تاکہ اس کی فارمیٹنگ اسی شکل میں رہے جس میں ہم اسے لکھتے ہیں:

@Test
public void testSummOfOddNumbers() {
	List<Integer> data = Arrays.asList(1, 4, 2, 3, 6, 7, 9);
	// @formatter:off
	Integer result = data.stream().filter(number -> number % 2 == 0)
                             .reduce((n1, n2) -> n1 + n2)
                             .get();
	assertThat(result, is(12));
	// @formatter:on
}

ہاں، اگر آپ نوٹس کرتے ہیں: جب آپ Tab کو دباتے ہیں، تو Idea اسے آپ کے لیے خالی جگہوں (پہلے سے طے شدہ برتاؤ) سے تعبیر کرتا ہے۔ لیکن آپ اسے وہاں Code Style میں تبدیل کر سکتے ہیں: جیسا کہ آپ دیکھ سکتے ہیں، ترتیبات کی ایک بہت بڑی قسم ہے۔ آپ یہاں کوڈ اسٹائل سیٹنگز کے بارے میں مزید پڑھ سکتے ہیں: " آئیڈیا ہیلپ: کوڈ اسٹائل "۔ فارمیٹنگ کی ایک اور اہم خصوصیت ہے - امپورٹ فارمیٹنگ۔ اسے الگ سے عمل میں لایا جاتا ہے اور کہا جاتا ہے "Optimize Imports"اور مینو آئٹم Code -> Optimize Imports(Ctrl + Alt + O) میں واقع ہے۔ امپورٹ آپٹیمائزیشن غیر ضروری امپورٹس کو ہٹاتی ہے اور جاوا سیٹنگز کے لیے کوڈ اسٹائل کے امپورٹس ٹیب میں سیٹنگز کے مطابق درست ترتیب میں بھی رکھتی ہے۔ اس کے علاوہ، اگر آپ چاہتے ہیں کہ فارمیٹنگ خود بخود ہوجائے، اچھی خبر یہ ہے کہ آپ اسے Save Actions پلگ ان کا استعمال کرکے کرسکتے ہیں ۔

کسی ٹیم میں ترتیبات کی تقسیم

بہت اچھا، ہم نے اوپر دیکھا کہ ہم فارمیٹنگ کے انداز کو اپنی مرضی کے مطابق بنا سکتے ہیں۔ لیکن اس انداز کو ٹیم میں کیسے استعمال کیا جا سکتا ہے؟ بہت آسان. کئی اختیارات ہیں۔ سب سے آسان ڈایاگرام کو محفوظ کرنا ہے۔ فائل -> سیٹنگز (یا Ctrl + Alt + S دبائیں) کے ذریعے آئیڈیا کی ترتیبات کھولیں۔ کوڈ اسٹائل سیکشن میں ہم انکرپشن اسکیم دیکھ سکتے ہیں۔ یہ ہماری فارمیٹنگ اسکیم ہے۔ پہلے سے طے شدہ طور پر، ایک اسکیم کو Default نام کے ساتھ مخصوص کیا جاتا ہے اور اس کے آگے IDE تشریح ہوتی ہے: اس کا مطلب ہے کہ یہ ترتیب صرف ہمارے IDE کے لیے ہے، اور یہ کسی کو متاثر نہیں کرتی ہے۔ "کسٹم" اسکیم بنانے کے لیے، "ڈپلیکیٹ" بنانے کے لیے دائیں جانب کے بٹن پر کلک کریں اور اسے ایک نام دیں، مثال کے طور پر: JavaRush اس کے بعد ہم ترتیبات کو درآمد یا برآمد کرنے کے قابل ہو جائیں گے: دوسرا آپشن امپورٹ آئیڈیا کی ترتیبات کو درآمد کرنا ہے: تیسرا آپشن سیٹنگز ریپوزٹری ہے۔ سیٹنگز ریپوزٹری کے استعمال کے بارے میں مزید معلومات کے لیے، "انٹیلی جے آئیڈیا ہیلپ: سیٹنگز ریپوزٹری " دستاویز دیکھیں ۔ ٹیم میں ایک ہی اسٹائل کی تقسیم کے موضوع پر، میں بھی مدد نہیں کرسکتا لیکن Eclipse IDE سے اسٹائل کے لیے اچھی حمایت کو نوٹ کر سکتا ہوں۔ ایسا کرنے کے لیے، آپ کو ایک الگ پلگ ان انسٹال کرنے کی ضرورت ہوگی: فائل -> سیٹنگز (Ctrl + Alt + S) کے ذریعے آئیڈیا کی ترتیبات کھولیں اور پلگ انز سیکشن میں جائیں۔ نئے پلگ انز کو تلاش کرنے کے لیے، بٹن پر کلک کریں "Browse Repositories"، جس کے بعد ہمیں سرچ ونڈو میں ایکلیپس کوڈ فارمیٹر پلگ ان ملے گا۔ اب، انسٹالیشن کے بعد، آپ کو آئیڈیا کو دوبارہ شروع کرنے کی ضرورت ہے - یہ ایک معیاری طریقہ کار ہے۔ اس کے بعد، اسی جگہ، آئیڈیا سیٹنگز میں، ہمیں ایک نیا سیکشن ملے گا: "Eclipse Code Formatter"۔ Eclipse کے لیے فارمیٹ فائل کی ایک مثال یہاں دیکھی جا سکتی ہے ۔ یہ کچھ اس طرح نظر آئے گا:

ضروریات کو سخت کرنا

آئیڈیا ٹولز کے علاوہ، آپ ضروریات کو سخت کرنے کے لیے بلڈ سسٹم پلگ ان بھی استعمال کر سکتے ہیں۔ یہ چیک کرنے کا کوئی طریقہ نہیں ہے کہ کسی شخص نے فارمیٹنگ کا استعمال کیا ہے۔ اگر ٹیم میں 5 لوگ ہیں تو یہ اب بھی ممکن ہے۔ اگر کمپنی میں 100 افراد ہیں، تو یہ غیر حقیقی ہے۔ جی ہاں، یہاں تک کہ پانچ کا ٹریک رکھنا مشکل ہوگا۔ اور اس پر وقت کیوں ضائع کیا؟ اگر کچھ اصولوں کی خلاف ورزی کی جاتی ہے تو کسی پروجیکٹ کو جمع کرنے پر پابندی لگانا بہت آسان ہے۔ درحقیقت یہ ایک مکمل علیحدہ موضوع ہے جسے "انسپیکٹ کوڈ" کہا جاتا ہے۔ اس مضمون کے مقاصد کے لیے، میں صرف یہ دکھانا چاہتا ہوں کہ یہ کیسے کام کرتا ہے۔ گریڈل کے لیے سب سے عام پلگ ان میں سے ایک ہے (چونکہ یہ ہمارے پروجیکٹ کو جمع کرتا ہے، اگر آپ کو یاد ہو) pmd ہے ۔ اسے فعال کرنے کے لیے، صرف ہمارے گریڈل پروجیکٹ کی بلڈ اسکرپٹ پر جائیں (ہمارے پروجیکٹ کے روٹ میں build.gradle فائل) اور اس میں باقی پلگ ان کے آگے pmd کی وضاحت کریں:

plugins {
    // Apply the java plugin to add support for Java
    id 'java'
    // Check source code
    id 'pmd'
    // Apply the application plugin to add support for building an application
    id 'application'
}

اب ہم وہاں مزید تفصیلی ترتیبات ترتیب دے سکتے ہیں:

pmd {
    ignoreFailures = false
    pmdTest.enabled = true
    ruleSets = [
            'java-basic',
            'java-braces',
            'java-clone',
            'java-codesize',
            'java-comments',
            'java-controversial',
            'java-coupling',
            'java-design',
            'java-empty',
            'java-finalizers',
            'java-imports',
            'java-optimizations',
            'java-strictexception',
            'java-strings',
            'java-typeresolution',
            'java-unnecessary',
            'java-unusedcode'
    ]
}

ہمارے پروجیکٹ میں بھی اب سب کچھ اچھا نہیں ہے۔ آئیے گریڈل بلڈ کو چلائیں اور ایک غلطی حاصل کریں۔ اچھی بات یہ ہے کہ اسمبلی کے دوران ایک رپورٹ تیار کی جاتی ہے۔ اور اگر غلطیاں ہوں تو ہمیں ایک پیغام ملے گا جیسے:

BUILD FAILED in 35s
6 actionable tasks: 6 executed
7 PMD rule violations were found. See the report at: file:///C:/_study/codestyle/build/reports/pmd/main.html

اگر ہم رپورٹ پر جائیں تو ہمیں کچھ اس طرح نظر آئے گا: مزید یہ کہ مسئلہ کالم میں pmd پلگ ان ویب سائٹ پر مسئلہ کی تفصیل کا لنک موجود ہے۔ مثال کے طور پر، "headerCommentRequirement Required" کی غلطی کے لیے لنک یہاں جاتا ہے: pmd - CommentRequired ۔ یہ غلطی ہمیں اشارہ کرتی ہے کہ ہماری کلاس میں JavaDoc نہیں ہے۔ کلاسوں پر جاوا ڈاک کی موجودگی کو ٹیمپلیٹس کا استعمال کرتے ہوئے ترتیب دیا جا سکتا ہے: اور فائل ہیڈر کے مواد کی وضاحت کریں: اس کے بعد، ہم ایپ کلاس کے اوپر والے تبصرے کو JavaDoc میں تبدیل کر سکتے ہیں اور ایک نئی Build کے ساتھ دیکھ سکتے ہیں کہ غلطی غائب ہو گئی ہے۔

نیچے کی لکیر

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

• JetBrainsTV کی طرف سے ویڈیو: " انسپیکٹ کوڈ (IntelliJ IDEA) "
• " گریڈل پلگ ان کے ساتھ کوڈ تجزیہ " کا جائزہ
• کورس " خودکار کوڈ کوالٹی "

#ویاچسلاو