Müasir alətlər inkişaf prosesini asanlaşdırır. Xüsusilə, kodunuzun "icazəsiz" formatını minimuma endirməyə çalışaraq üslubunu izləmək daha asandır. Bu baxışda mən IntelliJ Idea IDE-nin kodun oxunması xoş və asan başa düşülməsi üçün tərtibatçıya hansı alətlər təqdim etdiyi ilə tanış olmağı təklif edirəm.
Ekran görüntüsündə gördüyünüz kimi, "Zəncirvari üsul çağırışları" üçün parametri "həmişə sarın" kimi təyin edə bilərik, yəni. həmişə birləşdirilmiş metod çağırışları üçün bölünür. İndi testdə formatlamağa yenidən basaq və bunun həqiqətən işlədiyini görək! Amma bəzən elə olur ki, ümumi formatlaşdırma qaydalarından kənar hansısa kodun formatlanmasına ehtiyac yaranır. Formatlaşdırmanı aşağıdakı kimi quraq:
Formatlaşdırmanın deaktiv edilməsini aktivləşdirmək üçün Kod Stili bölməsində formatlaşdırma markerlərini söndürmək üçün dəstək aktivləşdirilməlidir:
İndi testimizin kodunu dəyişdirə bilərik ki, onun formatlanması onu yazdığımız formada qalsın:
Gördüyünüz kimi, çox sayda parametr var. Kod üslubu parametrləri haqqında daha ətraflı burada oxuya bilərsiniz: " Idea Help: Code Style ". Başqa bir vacib formatlama xüsusiyyəti var - idxal formatı. O, ayrıca yerinə yetirilir və çağırılır
Bundan sonra biz parametrləri idxal və ya ixrac edə biləcəyik:
Başqa bir seçim İdeya parametrlərini idxal etməkdir:
Üçüncü seçim Parametrlər Anbarıdır. Parametrlər Repozitoriyasından istifadə haqqında ətraflı məlumat üçün "IntelliJ Idea Help: Settings Repository " sənədlərinə baxın . Komandada vahid üslubun yayılması mövzusunda mən də Eclipse IDE-dən üslublara yaxşı dəstəyi qeyd etməyə kömək edə bilmirəm. Bunun üçün ayrıca plagin quraşdırmalı olacaqsınız: Fayl -> Parametrlər (Ctrl + Alt + S) vasitəsilə İdeya parametrlərini açın və Pluginlər bölməsinə keçin. Yeni plaginləri axtarmaq üçün düyməni basın
İndi quraşdırmadan sonra Idea-nı yenidən başlatmalısınız - bu standart prosedurdur. Bundan sonra, eyni yerdə, Idea parametrlərində biz yeni bir bölmə tapacağıq: "Eclipse Code Formatter" Eclipse üçün format faylının nümunəsini burada tapa bilərsiniz . Bu kimi bir şey görünəcək:
Bundan əlavə, Problem sütununda pmd plagininin veb saytında problemin təsvirinə keçid var. Məsələn, "headerCommentRequirement Tələb olunur" xətası üçün keçid bura gedir: pmd - CommentRequireed . Bu xəta bizim sinifimizdə JavaDoc olmadığını göstərir. JavaDoc-un siniflər üzərində mövcudluğu şablonlardan istifadə etməklə konfiqurasiya edilə bilər:
Və Fayl Başlığı üçün məzmunu təyin edin:
Bundan sonra biz Tətbiq sinifinin yuxarısındakı şərhi JavaDoc-a çevirə bilərik və yeni Quraşdırma ilə səhvin aradan qalxdığını görə bilərik.
Giriş
Proqramlaşdırma dili insanların danışdığı dilə çox oxşardır. Yeganə fərq ondadır ki, bu, əvvəlcə kompüterdən nə istədiyimizi izah etmək üçün onunla ünsiyyət qurmaq üçün istifadə olunan xüsusi bir dildir. Ancaq kompüterlə təkbətək ünsiyyət ola bilməz. Proqramlaşdırma dilini öyrənməyə başlayanda belə, siz kitaba və ya JavaRush kimi bəzi təhsil resursuna baxdınız. Və bu mənbədə kompüterin başa düşəcəyi kodu gördünüz. Ancaq Java dilini bildiyiniz zaman bunu başa düşməlisiniz. Hər bir dildə olduğu kimi, proqramlaşdırmanın da kodun formalaşdırılması üçün bəzi qaydaları var. Məsələn, nəzakətli cəmiyyətdə hasarla yazmaq pis davranış sayılır, Java-da isə metodu böyük hərflə çağırmaq kod üslubunun kobud şəkildə pozulmasıdır. Java kodunun formatlaşdırılması qaydaları Java Kodu Konvensiyası sənədində tərtib edilmişdir . Bundan əlavə, kod üslubu girinti kimi daha kiçik detalları tənzimləyə bilər. Və versiyaya nəzarət alətlərindən istifadə edildikdə, hər kəs faylı ya nişan kimi girintili, ya da boşluq kimi girintili saxladıqda bütün kabusu təsəvvür edin. Redaktəni yalnız bir üsulla yoxlamağa ehtiyacı olan biri üçün bu necə olacaq, lakin boşluqların nişanlara düzəldilməsi və ya əksinə bütün fayl dəyişdiriləcək. Təbii ki, adi dildə olduğu kimi, üslub da istifadə olunduğu yerdən asılı olaraq dəyişə bilər. Məsələn, İnternetdə siz Google Java Style Guide və ya Twitter Java Style Guide tapa bilərsiniz . Bu nəzərdən keçirmə məqaləsi üçün bizə bir test mövzusu lazımdır. Gəlin Gradle layihə qurma sisteminin xidmətindən istifadə edək. Tez bir başlanğıc üçün şablondan istifadə edərək yeni bir layihə yaratmağa imkan verəcəkdir. Gradle əla plaqinə malikdir: Init Plugin Build . Gəlin yeni kataloqa keçək və orada əmri yerinə yetirək:gradle init --type java-application
Bundan sonra IntelliJ Idea proqramını işə salın. Artıq açıq layihə olan bir pəncərə görsəniz (kod redaktorunu, layihə strukturu ağacını görəcəksiniz), istifadə edərək bu layihəni bağlayın File -< Close Project
. İndi qarşılama pəncərəsində "Import Project"
yeni layihəmizi icra edəcəyik və idxal edəcəyik. Import edərkən bayrağı təyin edin "Use autoimport"
. Müasir inkişaf vasitələrinin köməyi ilə həyatı bir şəkildə sadələşdirməyin mümkün olub olmadığını anlayaq.
İdeyada Kodun Formatlanması
Layihəni idxal etdikdən sonra düymələr birləşməsini basınCtrl+N
və sinfə keçin AppTest
. Bu sinif standart test sinfidir. Bu belə görünür:
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());
}
}
Burada dərhal diqqətinizi çəkən nədir? Bir sətirdə metod bəyannaməsi olan və çirkin görünən annotasiya razılaşır. Bunu necə düzəltmək olar? "Code"
IntelliJ Idea müxtəlif kod manipulyasiyaları üçün menyu bölməsinə malikdir . Belə manipulyasiyalardan biri də "Reformat Code"
açar birləşməsidir Ctrl + L
. Tətbiq edildikdən sonra annotasiya bir sətirdə, metodun özü isə digərində olacaq. Dərhal qeyd etmək lazımdır ki, bu əməliyyat kodun seçilmiş bölməsində həyata keçirilir . Və belə bir şey yoxdursa, formatlaşdırma əməliyyatı bütün məzmunda həyata keçiriləcək. İndi yeni bir test metodu əlavə edək:
@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));
}
Və iki idxal:
import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;
Gördüyünüz kimi, Stream-də əməliyyat bir sətirdə yerləşdirilir. Bəs zəngləri zəncirlənmiş metodların həmişə bir nöqtədə yeni sətirlərə bölündüyünə əmin olmaq istəsək nə olar? Bir tərəfdən, biz bunu əl ilə edə bilərik. Ancaq unutmayın ki, biz hər şeyin bizim üçün işləməsini istəyirik. Axı biz zaman-zaman unudacağıq və kod formatı hər yerdə fərqli olacaq və bu yaxşı deyil. Belə çıxır ki, siz Idea-nın formatlaşdırmanı yerinə yetirdiyi qaydanı redaktə etməlisiniz. Menyuda İdeya elementini seçin File -> Settings
(və ya klikləyin Ctrl + Alt + S
). Parametrlər pəncərəsindəki axtarış sahəsində "Kod tərzi" yazın. Code style bölməsində yalnız Java üçün deyil, parametrləri təyin etmək mümkündür. Ancaq indi Java ilə maraqlanırıq. Gördüyünüz kimi, parametrlər bir neçə nişana bölünür. Ən faydalısı odur ki, dəyişikliyin nəticəsi pəncərənin sağ tərəfindəki nümunədə göstəriləcək:
@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
}
Bəli, qeyd etsəniz: Tab düyməsini basdığınız zaman Idea onu sizin üçün boşluqlar kimi şərh edir (defolt davranış). Ancaq bunu Kod Stilində dəyişə bilərsiniz:
"Optimize Imports"
və menyu elementində yerləşir Code -> Optimize Imports
(Ctrl + Alt + O). İdxalın optimallaşdırılması lazımsız idxalları aradan qaldırır və həmçinin Java parametrləri üçün Kod Stilinin İdxallar sekmesindəki parametrlərə uyğun olaraq onları düzgün sıraya qoyur. Həmçinin, formatlaşdırmanın avtomatik baş verməsini istəyirsinizsə, yaxşı xəbər odur ki, Save Actions plaginindən istifadə edərək bunu edə bilərsiniz .
Parametrlərin Komandaya Paylanması
Əla, yuxarıda gördük ki, formatlaşdırma tərzini bizə uyğunlaşdıra bilərik. Bəs komandada bu üslubdan necə istifadə etmək olar? Çox sadə. Bir neçə variant var. Ən asanı diaqramı saxlamaqdır. Fikir parametrlərini Fayl -> Parametrlər vasitəsilə açın (və ya Ctrl + Alt + S düymələrini basın). Code Style bölməsində biz yazı sxemini görə bilərik. Bu bizim formatlaşdırma sxemimizdir. Varsayılan olaraq, Defolt adı ilə sxem müəyyən edilir və onun yanında IDE annotasiyası var: bu o deməkdir ki, bu parametr yalnız bizim IDE-miz üçündür və heç kimə təsir etmir. “Xüsusi” sxem yaratmaq üçün sağdakı düyməni sıxaraq “dublikat” yaradın və ona ad verin, məsələn: JavaRush"Browse Repositories"
, bundan sonra axtarış pəncərəsində Eclipse Code Formatter plaginini tapacağıq.
Sıxılma tələbləri
İdeya alətlərinə əlavə olaraq, tələbləri sərtləşdirmək üçün sistem qurma plaginlərindən də istifadə edə bilərsiniz. Bir şəxsin formatlaşdırmadan istifadə etdiyini yoxlamaq üçün heç bir yol yoxdur. Komandada 5 nəfər varsa, yenə də mümkündür. Əgər şirkətin 100 nəfəri varsa, bu qeyri-realdır. Bəli, hətta beş nəfəri izləmək çətin olacaq. Və niyə buna vaxt sərf edirsiniz? Müəyyən qaydalar pozulursa, layihənin toplanmasına qadağa qoymaq daha asandır. Əslində, bu, "Kodu yoxlayın" adlı bütöv bir ayrı mövzudur. Bu məqalənin məqsədləri üçün mən sadəcə bunun necə işlədiyini göstərmək istəyirəm. Gradle üçün ən çox yayılmış plaginlərdən biri (yadınızdadırsa, layihəmizi topladığı üçün) pmd- dir . Onu aktivləşdirmək üçün gradle layihəmizin qurma skriptinə (layihəmizin kökündəki build.gradle faylı) keçin və qalan plaginlərin yanında pmd yazın:
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'
}
İndi orada daha ətraflı parametrləri təyin edə bilərik:
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'
]
}
Hətta bizim layihədə də artıq hər şey yaxşı deyil. Gəlin gradle build-i işə salaq və xəta alırıq. Nə gözəl odur ki, montaj zamanı hesabat yaradılır. Səhvlər varsa, belə bir mesaj alacağıq:
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
Hesabata getsək, belə bir şey görəcəyik:
Alt xətt
Kod tərzi məhsuldar bir layihə üçün vacibdir. Ümumi qaydalara uyğun yazılmış gözəl kod həmkarlarınızın onu daha asan və tez başa düşəcəyinə və sizin haqqınızda bir-iki mehriban söz deməyəcəklərinə zəmanətdir. Müasir inkişaf vasitələrini nəzərə alsaq, qaydalara sadiq qalmaq o qədər də çətin deyil. Ümid edirəm ki, bu baxış bunun həqiqətən də belə olduğunu göstərdi. Həmişə olduğu kimi, mövzu ilə bağlı bir az material:- JetBrainsTV-dən video: " Kodu yoxlayın (IntelliJ IDEA) "
- " Gradle Pluginləri ilə Kod Təhlili " nə baxış
- " Kod keyfiyyətinin avtomatlaşdırılması " kursu
GO TO FULL VERSION