1. Giriş
Proqramlaşdırmada üslub — dəb üçün yox, yaşamaq üçündür. Java — böyük komandaların kod yazdığı dildir və əgər hər kəs “öz bildiyi kimi” yazsa, layihə tezliklə yalnız müəllifin (o da həmişə yox) anlaya biləcəyi əlaqəsiz hissələr yığınına çevriləcək.
Kod üslubu — hamı üçün kodu eyni dərəcədə oxunaqlı edən qaydalar toplusudur. Bu, yol nişanları kimidir: onları görməzdən gəlsəniz, hərəkət tez bir zamanda xaosa çevrilər.
Niyə bu vacibdir?
- Oxunaqlılıq: kodu yazmaqdan daha çox oxuyurlar. Pis üslub — həkimin pis xətti kimidir: heç kim orada nə yazıldığını başa düşməyəcək.
- Dəstəklənmə: əgər kod qaydalara uyğun yazılıbsa, onu dəyişmək asandır, təsadüfən nəyisə sındırma ehtimalı azalır.
- Komanda işi: komandada hamı artıq suallar olmadan bir-birini başa düşməlidir.
- Alətlər: autoformatlayıcılar və kod analizatorları üslub vahid olanda daha yaxşı işləyir.
2. Kod üslubundakı əsas səhvlər (və onlardan necə qaçmaq olar)
İndentlər və mötərizələrə əməl edilməməsi
Səhv:
İndentsiz və xaotik mötərizələrlə kod gözlər və beyin üçün əzabdır.
if(x>0){
System.out.println("x müsbətdir");
}else{
System.out.println("x müsbət deyil");
}
Necə olmalıdır:
if (x > 0) {
System.out.println("x müsbətdir");
} else {
System.out.println("x müsbət deyil");
}
Şərh:
Hər iç-içəlik səviyyəsi üçün dörd boşluq istifadə edin (bu, Java standartıdır). Tabulyasiya — pisdir, yalnız bütün komanda başqa cür razılaşmayıbsa.
Dəyişənlərin, metodların və siniflərin yanlış adlandırılması
Səhv:
int a = 5;
String s = "Vasya";
void f() { /* ... */ }
Necə olmalıdır:
int age = 5;
String userName = "Vasya";
void printReport() { /* ... */ }
Şərh:
Adlar məna kəsb etməli və dəyişənin və ya metodun mahiyyətini əks etdirməlidir.
- Siniflər — böyük hərflə, CamelCase: UserAccount.
- Metodlar və dəyişənlər — kiçik hərflə, camelCase: calculateSalary, userList.
Həddindən artıq uzun metodlar və siniflər
Səhv:
100 sətirlik metod, 1000 sətirlik sinif — dəstək üçün əsl nightmare mode.
Necə olmalıdır:
Hər metod bir şeyi etməli və qısa olmalıdır (ideal — ekrana sığar). Siniflər də “Müharibə və sülh” ölçülərinə qədər böyüməməlidir.
Nümunə:
Pis:
public void processOrder() {
// 200 sətir kod
}
Yaxşı:
public void processOrder() {
validateOrder();
calculateTotal();
saveToDatabase();
sendEmailConfirmation();
}
“Magic numbers” və sətirlərdən istifadə
Səhv:
if (status == 42) {
// ...
}
Necə olmalıdır:
public static final int STATUS_APPROVED = 42;
if (status == STATUS_APPROVED) {
// ...
}
Şərh:
“Magic numbers” və sətirlər əvəzinə konstansiyalardan istifadə edin (static final). Java-nın yeni versiyalarında bunun üçün enum da var — məhdud dəyər dəstləri üçün onlardan istifadə edin.
Şərhlər: ya yoxluğu, ya da həddən artıq olması
Səhv 1:
Ümumiyyətlə şərh yoxdur — mürəkkəb kodun nə etdiyini anlamaq çətindir.
Səhv 2:
Hər bir əmələ, hətta aşkar olanlara belə şərh yazmaq.
// x-i 1 vahid artırırıq
x = x + 1;
// x-in 10-a bərabər olub-olmadığını yoxlayırıq
if (x == 10) {
// ...
}
Belə şərhlər yalnız mane olur! Yalnız mürəkkəb və ya qeyri-aşkar məqamları şərh edin. Ümumiyyətlə, yaxşı kod şərhsiz də başa düşülməlidir — şərhlər “nə”yi yox, “nəyə görə”ni izah etmək üçündür.
// VIP müştərilər üçün endirimi nəzərə alırıq
double total = calculateTotalWithDiscount();
3. Java konvensiyaları: peşəkarlar necə yazır
Java-da rəsmi və de-fakto tərtibat standartları var. Oracle Java Code Conventions və Google Java Style Guide — ən populyarlarıdır.
İndentlər və mötərizələr
Açıq fiqurlu mötərizə elanın olduğu sətirdə qoyulur:
public void print() {
// ...
}
Daxillik — dörd boşluqdur.
Adlandırma
- Siniflər və interfeyslər: CamelCase və böyük hərflə (Person, UserAccount).
- Metodlar və dəyişənlər: kiçik hərflə camelCase (calculateSalary, userList).
- Konstansiyalar: HAMISI_BÖYÜK_HƏRFLƏRLƏ_VƏ_ALT_XƏTTLƏ (MAX_SIZE, DEFAULT_TIMEOUT).
- Paketlər: yalnız kiçik hərflər, nöqtələrlə ola bilər (com.example.project).
Boşluqlar
Operatorların ətrafında və vergüllərdən sonra boşluq:
int sum = a + b;
System.out.println(name, age);
Açan mötərizədən sonra və bağlayan mötərizədən əvvəl boşluq qoymayın:
if (x > 0) { ... }
Sətir uzunluğu
Bir sətirdə 100–120 simvolu keçməmək tövsiyə olunur. (Bəli, monitorunuz böyükdür, amma kod yenə də üfüqi olaraq daşmayan halda daha yaxşı oxunur.)
Sinif üzvlərinin elan olunma ardıcıllığı
Tövsiyə olunan ardıcıllıq (Oracle-a görə):
- Sahələr (öncə statik, sonra adi)
- Konstruktorlar
- Metodlar
Nümunə:
public class User {
private static int userCount;
private String name;
public User(String name) {
this.name = name;
userCount++;
}
public String getName() {
return name;
}
}
4. Nümunə: pis üslubun refaktorinqi
Vəhşi təbiətdə rast gələ biləcəyiniz sinif nümunəsi:
class person{String n;int a;void p(){System.out.println(n+" "+a);}}
Haradasa ofisdə bu koda görə bir Java inkişaf etdirəni ağlayır.
Gəlin onu yaxşılaşdıraq:
public class Person {
private String name;
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public void print() {
System.out.println(name + " " + age);
}
}
Nələr dəyişdi:
- Sinif və üzvlər düzgün giriş modifikatorları ilə.
- Adlar mənalı və oxunaqlıdır.
- Hər bir sinif üzvü yeni sətirdən.
- İlkləndirmə üçün konstruktor istifadə olunur.
- Sahələr private olaraq, enkapsulyasiya qorunur.
5. Faydalı incəliklər
Autoformatlayıcılar
Müasir IDE-lər (IntelliJ IDEA, Eclipse, VS Code) kodu standartlara görə avtomatik formatlaya bilir.
Qaynar düymələr:
- IntelliJ IDEA: Ctrl + Alt + L
- Eclipse: Ctrl + Shift + F
Statik analiz
Checkstyle, SonarLint, PMD kimi alətlər proqram işə düşməzdən əvvəl üslub pozuntularını və potensial səhvləri aşkar etməyə kömək edir.
Bu necə görünür:
- Checkstyle-də dəyişəninizi x yox, userAge adlandırmadığınız üçün xəbərdarlıq ediləcək.
- SonarLint metod çox uzundursa və ya sinif SOLID prinsiplərini pozursa, bunu göstərəcək.
Məsuliyyətin bölünməsi və “təmiz” kod
- Hər sinif yalnız bir vəzifəyə cavabdeh olmalıdır (Single Responsibility Principle).
- Əlavə sinif və metodlar yaratmaqdan çəkinməyin — bu “şişirtmə” deyil, gələcək oxucunu düşünməkdir.
- Kod təkrarlanmasından qaçın: iki oxşar fraqment görürsünüzsə — onları ayrıca metoda çıxarın.
Konstansiyalar və “magic numbers”: necə düzgün
Bunun əvəzinə:
double price = 100 * 0.18;
Daha yaxşısı:
public static final double VAT_RATE = 0.18;
double price = 100 * VAT_RATE;
Və əgər sizdə tez-tez sabit dəyər dəstləri rast gəlinirsə — enum istifadə edin:
public enum Status {
NEW, IN_PROGRESS, DONE
}
6. Kod üslubu və oxunaqlılığında tipik səhvlər
Səhv №1: Kod konvensiyalarını görməzdən gəlmək.
Komandada vahid üslub yoxdursa, kod tez bir zamanda oxunmaz və dəstəklənməsi çətin olur. Hətta tək yazsanız belə, bir ildən sonra özünüz özünüzə təşəkkür edəcəksiniz.
Səhv №2: Həddən artıq qısa/uzun adlar.
Dəyişən a və ya temp — pisdir. Dəyişən theCurrentUserNameThatIsUsedForAuthorizationInTheSystem — buna da ehtiyac yoxdur. Balans tapın: userName, age, bookList.
Səhv №3: “Magic numbers”.
Rəqəmləri və sətirləri birbaşa kodun içinə qoymaq dəstəyi çətinləşdirir və səhvlərin ehtimalını artırır.
Səhv №4: Nəhəng metodlar və siniflər.
Metod nə qədər böyükdürsə — onu test etmək və anlamaq bir o qədər çətindir. Loji hissələrə bölün.
Səhv №5: Sinifin zəif strukturu.
Sahələr hər yerdə səpələnib, metodlar təsadüfi qaydada elan edilib — bunların hamısı lazımi yeri tez tapmağa mane olur.
Səhv №6: Həddən artıq və ya çatışmayan şərhlər.
int x = 0; yanında “dəyişənin ilkləndirilməsi” şərhi lazım deyil. Mürəkkəb biznes məntiqini izah edən şərh isə çox lazımdır.
Səhv №7: Uyğunsuz formatlaşdırma.
Layihənin bir hissəsində — dörd boşluq, digərində — tabulyasiya; burada mötərizə yeni sətirdə, orada — köhnə sətirdə. Bu, səliqəsiz görünür və həmkarları əsəbiləşdirir.
GO TO FULL VERSION