“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” Martin Fowler
Refaktorisanje je proces preuređivanja i poboljšavanja postojećeg koda bez promene njegovog spoljašnjeg ponašanja. Ova praksa je osmišljena da unapredi čitljivost, održavanje i skalabilnost koda.
Čist kod je jasan, razumljiv i održiv.
Zašto treba pisati čist kod?
Prilikom imenovanja promenljivih, metoda, klasa, … se treba truditi da ih imenujete smisleno i da im ime ne bude predugačko.
| Konvencija | Primer |
|---|---|
| Pascal Case | PascalCase |
| Camel Case | camelCase |
| Snake Case | snake_case |
| Screaming Snake Case | SCREAMING_SNAKE_CASE |
| Kebab Case | kebab-case |
| Lower Dot Case | lower.dot.case |
| Upotreba | Konvencija |
|---|---|
| promenljive i metodi | Camel Case |
| klase i interfejsi | Pascal Case |
| konstante | Screaming Snake Case |
| paketi | Lower Dot Case |
Više o tome možete videti na sledećoj prezetaciji.
Smernice navedene u nastavku nisu obavezne, ali je preporučljivo ispratiti ih kako bi vaš kod bio čist. Iako postoje alati koji mogu sami da formatiraju kod u skladu sa standardima, nije na odmet proći neke osnovne standarde pisanja koda.
if (condition) {
} else {
}
Razmak nakon if i između ) i {.
Razmak pre i posle else.
for (initialization; condition; steps) {
}
while (condition) {
}
Slično kao i za if.
do {
}
while (condition);
switch (expression) {
case x:
// code block
break;
case y:
// code block
break;
default:
// code block
}
class Klasa {
}
interface Interfejs {
}
Između naziva i { bi trebalo da postoji razmak.
void metoda(argument1, argument2) {
}
Između , i narednog argumenta i ) i { bi trebalo da postoji razmak.
(int) 4.2
!true
-4
++a
c--
Ne postoji razmak između operatora i vrednosti ili promenljive.
a = 10;
a += 13;
true && false;
1 + 2
3 / 6
...
Razmak pre i posle operatora.
(condition) ? expressionTrue : expressionFalse;
int a; // razmak pre i nakon //
int c; /* razmak pre i nakon
*/
// ukoliko je samo komentar u liniji razmak nakon //
/* isto vazi i ovde
*/
Treba brisati nepotrebne linije kao na primer poslednju praznu liniju u fajlu. Linije koje nije preporučljivo brisati su linija pre i linija nakon blokova
metode, if, switch i petlji (for, while, do while). Ukoliko je nakon ovih navedenih blokova } a ne neki koristan kod, onda je preporučljivo obrisati praznu liniju između njih.
Primer
class Test {
void metoda1() {
}
// postoji prazna linija
void metoda2() {
}
// postoji prazna linija
void metoda3() {
} // ne postoji prazna linija nakon ovoga
}
void test() {
int a,b;
String c;
// postoji prazna linija
for () {
}
// postoji prazna linija
while () {
} // postoji prazna linija
}
DRY je akronim za “Don’t Repeat Yourself” (Ne Ponavljaj Se). Ovo je princip softverskog inžinjeringa koji promoviše smanjenje ponavljanja koda u softverskim projektima.
Glavne prednosti DRY principa uključuju:
Smanjenje redundanse: Izostavljanje ponavljanja smanjuje količinu koda i podataka, čineći sistem efikasnijim.
Poboljšana održivost: Kada se funkcionalnost ili podaci ponavljaju na više mesta, svaka promena mora biti ažurirana na svakom od tih mjesta. To može dovesti do grešaka i otežati održavanje koda.
Povećana čitljivost: Kada se informacije ponavljaju, kod postaje duži i teži za čitanje. DRY princip olakšava razumevanje koda jer se ista funkcionalnost ili podaci nalaze na jednom mestu.
DRY princip se obično primenjuje na više nivoa razvoja softvera:
KISS princip je akronim za “Keep It Simple, Stupid”. Ovaj princip se odnosi na filozofiju dizajniranja, razvoja softvera ili sistemskih arhitektura, gde se promoviše jednostavnost i minimalizam.
Baeldung
Academind slajdovi
Academind sumirano
Evo šta svaki od SOLID principa znači:
S - Single Responsibility Principle (Princip jedne odgovornosti): Svaka klasa treba da bude odgovorna samo za jedan aspekt funkcionalnosti. Ovo znači da klasa treba da ima samo jedan razlog za promenu.
O - Open/Closed Principle (Princip otvorenosti/zatvorenosti): Klase treba dizajnirati tako da budu otvorene za proširenje, ali zatvorene za modifikacije. To znači da treba biti moguće proširiti funkcionalnost bez menjanja postojećeg koda.
L - Liskov Substitution Principle (Liskov princip zamene): Ovaj princip kaže da objekti podklase mogu da budu zamena (substitutable) za objekte svoje nadklase bez narušavanja ispravnosti programa. Drugim rečima, potklasa treba da bude kompatibilna sa svojom nadklasom.
I - Interface Segregation Principle (Princip segregacije interfejsa): Interfejsi treba da budu specifični za korisnike, tako da oni ne moraju zavisiti od funkcionalnosti koje ne koriste. Veliki interfejsi treba razbiti na manje specifične segmente kako bi se omogućila veća fleksibilnost.
D - Dependency Inversion Principle (Princip inverzije zavisnosti): Moduli visokog nivoa ne bi trebalo da zavise od modula niskog nivoa. Trebalo bi da zavise od apstrakcija. Apstrakcije ne bi trebale zavisiti od detalja. Detalji bi trebali zavisiti od apstrakcija. Ovaj princip se fokusira na smanjenje zavisnosti između klasa. To se postiže korišćenjem apstrakcija i interfejsa, umesto da se klase direktno vezuju za implementacije drugih klasa.