Najczęściej Łamane Zasady Czystego Kodu

Powielanie – duplication

Ten sam kod występuje więcej niż raz. Jeśli nie jest to zamierzone, powinno zostać refaktoryzowane poprzez przeniesienie tego kodu do oddzielnej klasy i / lub metody.
Zgodnie z zasadą „Nie powtarzaj się” (DRY).

Zbyt duże klasy / metody

Klasy i metody powinny być jak najmniejsze. Powinni mieć „tylko jeden powód do zmiany”, tak jak mówi zasada pojedynczej odpowiedzialności, o której już pisałem we wcześniejszych postach. Typowe zapachy kodów to:
– za dużo linii kodów
– zbyt wiele zależności (parametry konstruktorów / metod)
– kod w klasie dotyczący różnych przypadków użycia.

Niewykorzystany kod

Niewykorzystany kod jest tworzony w 2 przypadkach.

Pierwszym przypadkiem jest sytuacja,gdy kod został zmieniony (z powodu refaktoryzacji lub zmiany wymagań) i teraz część tego kodu jest nieprawidłowa.

Drugi przypadek ma miejsce, gdy programista chciał dodać jakąś dodatkową funkcjonalność na zapas, która nie jest wymagana w momencie pisania, ale uważa, że może być potrzebna później.

W obu przypadkach nieużywany kod nie powinien istnieć, dodaje niepotrzebnej złożoności – należy tego unikać. Istnieje nawet zasada programowania dla drugiego przypadku – zasada YAGNI.

Magiczne ciągi i liczby

Programowanie jest wystarczająco skomplikowane i trudne nawet bez magii. Kod z bezsensownymi ciągami i liczbami, takimi jak :
client == 1,
customer.Type = ‘AD’
jest trudny do odczytania, utrzymania i refaktoryzacji. Zamiast tego powinniśmy używać wyliczeń i stałych oraz cieszyć się dobrą czytelnością i sprawdzeniami w czasie kompilacji.

Za dużo instrukcji warunkowych

Czasami, gdy logika biznesowa jest skomplikowana, widzimy dużo zagnieżdżonych instrukcji if / else.
Trudno to przeczytać i zrozumieć. Często możemy pozbyć się części tych instrukcji stosując jakiś wzorzec i zasadę projektową na przykład Zasadę Open/Closed i wzorzec strategii.

Brak hermetyzacji

Jest to najczęściej łamana zasada czystego kodu i paradygmatu projektowania obiektowego, łamanie jej spotykamy prawie w każdym kodzie. Każda klasa jest publiczna z publicznymi właściwościami i publicznymi metodami. To nie jest programowanie obiektowe.

Naszym obowiązkiem jest tworzenie obiektów całkowicie zamkniętych i ukrywanie ich wnętrzności. Przestań ujawniać wewnętrzne elementy swoich klas tylko dlatego, że twoje IDE domyślnie dodaje słowo kluczowe public.

Niechlujne formatowanie

Nie wpływa to na wykonanie naszego kodu, ale wpływa na czytelność. Niektórzy powiedzą, że to drobny problem, ale ja powiem, że tak nie jest. Co myślisz o książce, która nie jest dobrze sformatowana?

W programowaniu powinniśmy mieć te same zasady, ponieważ jesteśmy a przynajmniej chcemy być profesjonalistami!

Za dużo komentarzy

Komentarze z linii 1, 4, 7, 18 nie są potrzebne, ponieważ kod mówi sam za siebie.
Blok komentarzy z linii 14-16 i 21-22 też nie jest potrzebny, ten kod powinien zostać usunięty. Kontrola źródła (Git) zapamięta wszystko.

Komentarze są potrzebne tylko w dwóch przypadkach:
– komentowanie publicznego API.
– gdy programista używa jakiegoś hacka i nie ma innego sposobu, aby to wyjaśnić.

W innych przypadkach komentarze są niepotrzebne i należy ich unikać.
Zamiast tego powinieneś użyć techniki refaktoryzacji zwanej Extract Method.

Złe i niespójne nazewnictwo

Nazewnictwo jest bardzo często pomijane, szczególnie przez mniej doświadczonych programistów, a nie powinno tak być. Dobre nazewnictwo czasami a nawet często jest trudne, ale jest potrzebne do poprawienia poprawności kodu i łatwości utrzymania.

Zła obsługa wyjątków

Zawsze powinniśmy łapać najbardziej specyficzny wyjątek np. DivideByZeroException .
Co więcej, powinniśmy być ostrożni podczas próby ponownego wyrzucenia danego wyjątku, ponieważ możemy utracić informacje o całym stosie.