IntelliJ IDEA: سبک کد و قالب بندی

ابزارهای مدرن روند توسعه را آسان تر می کنند. به طور خاص، نظارت بر سبک کد شما آسان تر است و سعی می کنید قالب بندی "غیر مجاز" آن را به حداقل برسانید. در این بررسی، پیشنهاد می‌کنم با ابزارهایی که IntelliJ Idea IDE در اختیار توسعه‌دهنده قرار می‌دهد آشنا شوید تا کد را برای خواندن و درک آن آسان کند.

معرفی

یک زبان برنامه نویسی بسیار شبیه به زبانی است که مردم به آن صحبت می کنند. تنها تفاوت این است که این یک زبان خاص است که در ابتدا برای برقراری ارتباط با رایانه استفاده می شود تا به آن توضیح دهیم که از آن چه می خواهیم. اما نمی توان با یک کامپیوتر ارتباط انفرادی برقرار کرد. حتی زمانی که شروع به یادگیری یک زبان برنامه نویسی کردید، به یک کتاب یا منابع آموزشی مانند JavaRush نگاه می کردید. و در این منبع کدی را دیدید که یک کامپیوتر آن را درک خواهد کرد. اما با کسب دانش زبان جاوا نیز باید آن را درک کنید. مانند هر زبان دیگری، برنامه نویسی قوانینی برای تشکیل کد دارد. به عنوان مثال، نوشتن با حصار در جامعه مودبانه رفتار بد تلقی می شود و در جاوا نامیدن متد با حروف بزرگ نقض فاحش سبک کد است. قوانین قالب بندی کد جاوا در سند قرارداد کد جاوا فرموله شده است . علاوه بر این، سبک کد می تواند جزئیات کوچکتر مانند تورفتگی را تنظیم کند. و هنگامی که از ابزارهای کنترل نسخه استفاده می شود، کل کابوس را تصور کنید که همه فایلی را که به صورت برگه یا به صورت فاصله تورفتگی شده ذخیره می کنند. برای کسی که باید ویرایش را فقط در یک روش بررسی کند، اما کل فایل به دلیل اصلاح فاصله ها به تب ها تغییر می کند یا برعکس، چگونه خواهد بود. طبیعتاً، مانند زبان معمولی، سبک ممکن است بسته به محل استفاده متفاوت باشد. برای مثال، در اینترنت می‌توانید Google Java Style Guide یا Twitter Java Style Guide را پیدا کنید . برای این مقاله مروری، به یک موضوع آزمایشی نیاز داریم. بیایید از سرویس سیستم ساخت پروژه Gradle استفاده کنیم. به ما این امکان را می دهد که برای شروع سریع یک پروژه جدید با استفاده از یک الگو ایجاد کنیم. Gradle یک پلاگین عالی دارد: Build Init Plugin . بیایید به دایرکتوری جدید برویم و دستور را در آنجا اجرا کنیم: 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());
    }
}

چه چیزی در اینجا بلافاصله نظر شما را جلب می کند؟ حاشیه نویسی با اعلان روش در یک خط، که زشت به نظر می رسد، موافق است. چگونه این را رفع کنیم؟ "Code"IntelliJ Idea یک بخش منو برای دستکاری کدهای مختلف دارد . یکی از این دستکاری ها "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;

همانطور که می بینید، عملیات در Stream در یک خط قرار می گیرد. اما اگر بخواهیم مطمئن شویم که روش هایی که فراخوانی آنها زنجیره ای است همیشه در یک نقطه به خطوط جدید تقسیم می شوند، چه؟ از یک طرف، ما می توانیم این کار را به صورت دستی انجام دهیم. اما به یاد داشته باشید که ما می خواهیم همه چیز برای ما کار کند. از این گذشته ، هر از گاهی فراموش می کنیم و قالب کد در همه جا متفاوت می شود و این خوب نیست. به نظر می رسد که باید قاعده ای را ویرایش کنید که توسط Idea قالب بندی را انجام می دهد. مورد ایده را در منو انتخاب کنید File -> Settings(یا روی آن کلیک کنید Ctrl + Alt + S). در قسمت جستجو در پنجره تنظیمات، "سبک کد" را بنویسید. در بخش Code style امکان تعیین تنظیمات نه تنها برای جاوا وجود دارد. اما اکنون ما به جاوا علاقه مندیم. همانطور که می بینید، تنظیمات به چندین تب تقسیم می شوند. آنچه که بسیار مفید است این است که نتیجه تغییر در یک مثال در سمت راست پنجره نشان داده می شود: همانطور که در اسکرین شات مشاهده می کنید، می توانیم تنظیمات "Chained method calls" را به صورت "wrap always" تعیین کنیم. همیشه برای فراخوانی روش ادغام شده تقسیم می شود. حالا بیایید دوباره در تست قالب بندی را فشار دهیم و ببینیم که واقعا کار می کند! اما گاهی اوقات پیش می آید که نیاز به فرمت کردن برخی کدها خارج از قوانین قالب بندی کلی وجود دارد. بیایید قالب بندی را به صورت زیر تنظیم کنیم: برای فعال کردن غیرفعال کردن قالب بندی، پشتیبانی از نشانگرهای قالب بندی غیرفعال باید در بخش Code Style فعال شود: اکنون می توانیم کد تست خود را طوری تغییر دهیم که قالب بندی آن به شکلی که در آن می نویسیم باقی بماند:

@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) قرار دارد. Import Optimization واردات های غیر ضروری را حذف می کند و همچنین طبق تنظیمات موجود در تب Imports در Code Style برای تنظیمات جاوا آنها را به ترتیب صحیح قرار می دهد. همچنین، اگر می‌خواهید قالب‌بندی به صورت خودکار انجام شود، خبر خوب این است که می‌توانید آن را با استفاده از افزونه Save Actions انجام دهید .

توزیع تنظیمات در یک تیم

عالی است، در بالا دیدیم که می‌توانیم سبک قالب‌بندی را مطابق با ما سفارشی کنیم. اما چگونه می توان از این سبک در یک تیم استفاده کرد؟ بسیار ساده. چندین گزینه وجود دارد. ساده ترین راه این است که نمودار را ذخیره کنید. تنظیمات Idea را از طریق File -> Settings باز کنید (یا Ctrl + Alt + S را فشار دهید). در قسمت Code Style می توانیم کتیبه Scheme را ببینیم. این طرح قالب بندی ما است. به طور پیش فرض، یک طرح با نام Default مشخص شده است و در کنار آن حاشیه نویسی IDE قرار دارد: این بدان معنی است که این تنظیمات فقط برای IDE ما است و هیچ کسی را تحت تأثیر قرار نمی دهد. برای ایجاد یک طرح "سفارشی"، روی دکمه سمت راست کلیک کنید تا یک "تکراری" ایجاد کنید و نامی برای آن بگذارید، به عنوان مثال: JavaRush پس از این، ما قادر خواهیم بود تنظیمات را وارد یا صادر کنیم: گزینه دیگر وارد کردن تنظیمات Import Idea است: گزینه سوم Settings Repository است. برای اطلاعات بیشتر در مورد استفاده از مخزن تنظیمات، به مستندات "IntelliJ Idea Help: Settings Repository " مراجعه کنید. در مورد توزیع یک سبک واحد در تیم، من همچنین نمی توانم به پشتیبانی خوب از سبک های Eclipse IDE توجه نکنم. برای انجام این کار، باید یک افزونه جداگانه نصب کنید: تنظیمات Idea را از طریق File -> Settings (Ctrl + Alt + S) باز کنید و به بخش Plugins بروید. برای جستجوی افزونه های جدید، روی دکمه کلیک کنید "Browse Repositories"، پس از آن افزونه Eclipse Code Formatter را در پنجره جستجو پیدا می کنیم. اکنون، پس از نصب، باید Idea را مجددا راه اندازی کنید - این یک روش استاندارد است. پس از آن، در همان مکان، در تنظیمات Idea، یک بخش جدید پیدا می کنیم: "Eclipse Code Formatter" نمونه ای از یک فایل فرمت برای Eclipse را می توانید در اینجا پیدا کنید . چیزی شبیه به این خواهد بود:

الزامات سفت کردن

علاوه بر ابزارهای ایده، می‌توانید از افزونه‌های سیستم ساخت نیز برای سخت‌تر کردن الزامات استفاده کنید. هیچ راهی برای بررسی اینکه آیا شخصی از قالب بندی استفاده کرده است وجود ندارد. اگر 5 نفر در تیم حضور داشته باشند، باز هم امکان پذیر است. اگر شرکت 100 نفر داشته باشد، غیرواقعی است. بله، حتی ردیابی پنج مورد نیز دشوار خواهد بود. و چرا وقت را برای این موضوع تلف کنیم؟ اگر قوانین خاصی نقض شود، ممنوع کردن جمع آوری یک پروژه بسیار ساده تر است. در واقع، این یک موضوع کاملاً جداگانه است به نام "بازرسی کد". برای اهداف این مقاله، من فقط می خواهم نشان دهم که چگونه کار می کند. یکی از رایج ترین پلاگین ها برای Gradle (از آنجایی که پروژه ما را جمع آوری می کند، اگر به خاطر داشته باشید) pmd است . برای فعال کردن آن، کافیست به اسکریپت ساخت پروژه gradle خود (فایل 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'
    ]
}

حتی در پروژه ما دیگر همه چیز خوب نیست. بیایید gradle build را اجرا کنیم و یک خطا دریافت کنیم. آنچه خوب است این است که یک گزارش در طول مونتاژ تولید می شود. و در صورت وجود خطا، پیامی مانند:

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 روی کلاس ها را می توان با استفاده از قالب ها پیکربندی کرد: و محتویات File Header را مشخص کنید: پس از این، می توانیم کامنت بالای کلاس App را به JavaDoc تبدیل کنیم و با یک Build جدید ببینیم که خطا ناپدید شده است.

خط پایین

سبک کد برای یک پروژه سازنده مهم است. کد زیبا که بر اساس قوانین کلی نوشته شده است، تضمینی است که همکاران شما آن را راحت تر و سریعتر درک می کنند و دوتا حرف محبت آمیز در مورد شما نمی گویند. با توجه به ابزارهای توسعه مدرن، پایبندی به قوانین چندان دشوار نیست. امیدوارم این بررسی نشان داده باشد که واقعاً چنین است. خوب، طبق معمول، مطالب کمی در مورد موضوع:

• ویدیو از JetBrainsTV: " Inspect Code (IntelliJ IDEA) "
• بررسی " تحلیل کد با پلاگین های Gradle "
• دوره آموزشی " کیفیت کد خودکار "

#ویاچسلاو