Free Press

Witamy w cudownym świecie tworzenia oprogramowania. Przygotuj się na ekscytującą i porywającą podróż wypełnioną kodem, zasadami i jeszcze większą ilością kodu. A czy wspomniałem, że są tam zasady? Jeśli jesteś kimś, kto jest zaznajomiony z kodowaniem, to koncepcja standardów kodowania nie jest dla Ciebie niczym nowym. Możesz być zdecydowanym zwolennikiem tych wytycznych lub bojownikiem o wolność, który wierzy, że kod jest formą ekspresji. Cokolwiek by to nie było, nie zaszkodzi spojrzeć na niektóre z najlepszych praktyk, jeśli chodzi o pisanie dobrego kawałka kodu.
Warto wspomnieć, że podczas gdy standardy kodowania istnieją – istnieją one w wielu odmianach i często są tylko wytycznymi, które nie muszą być przestrzegane. Jeśli nie chcesz pisać dobrego kodu, to prawdopodobnie powinieneś trzymać się jakiejś formy standardów.

Pisz komentarze i dokumentację

Prawdopodobnie jedną z pierwszych rzeczy, których uczysz się jako programista, jest komentowanie kodu. Na początku może się to wydawać stratą czasu, podążając za mentalnością „Jeśli oni też są programistami – mogą to zrozumieć”. Chociaż w niektórych przypadkach jest to prawda, komentowanie kodu i dostarczanie odpowiedniej dokumentacji poprowadzi innych programistów przez algorytm i logikę, którą zaimplementowałeś. Ale nie daj się ponieść i nie komentuj każdej linii kodu! Oczywisty kod powinien być pozostawiony jako taki.

Pisz czytelny, ale wydajny kod

Czytelne kody są łatwe do śledzenia, ale wykorzystują optymalną przestrzeń i czas. Podczas pisania kodu często możesz chcieć napisać go w jak najmniejszej ilości linii. Być może można napisać całą metodę lub funkcję w jednej linii, ale to tylko utrudnia czytanie i zrozumienie.

Używaj metod pomocniczych

Dobrą praktyką jest utrzymywanie kodu zwięzłego i treściwego. Metoda powinna implementować tylko to, co musi zrobić. Jeśli część twojej implementacji robi coś innego, umieść ją w osobnej metodzie i wywołaj ją w swojej metodzie.

Jeśli można tego uniknąć, NIE TWARDO KODUJ!

Jedyne rzeczy, które powinny być twardo kodowane, to stałe. To jest to.

Pisz przypadki testowe. Nie zapomnij o przypadkach brzegowych: 0s, puste ciągi/listy, nulls, etc.

W ten sposób wiesz, co robi twoja metoda, co pobiera i co powinna zwrócić. Będziesz wiedział kiedy powinna zadziałać lub kiedy powinna zawieść. Funkcja powinna być zawsze oparta na przypadkach testowych; nie na testach funkcji.

Pisz czytelny, ale wydajny kod.Zgodny ze standardami kodowania twojego aktualnego projektu

„DISCIPLINED PERSONAL PRACTICES CAN REDUCE DEFECT INTRODUCTION RATES BY UP TO 75 PERCENT”

Każdy projekt/firma ma swoje własne standardy kodowania. Niektórzy mogą preferować jeden styl nad drugim, jeśli chodzi o takie rzeczy jak konwencje nazewnictwa, struktura plików i odstępy.
Istnieją IDE, w których można ustawić preferowany styl, który będzie automatycznie korygowany podczas zapisywania. Łatwiej jest czytać, a więc i rozumieć, gdy wszystkie pliki projektu używają tego samego stylu, konwencji nazewnictwa, odstępów itp.

Użyj menu rozwijanego swojego IDE

Nie tyle standard, co dobra praktyka, są one bardzo pomocne i pomogą ci popełnić mniej błędów w kodowaniu.

Na przykład:
Jeśli chcesz zmienić nazwę zmiennej lub metody, po prostu użyj opcji „refactor” w swoim IDE, a zmieni ona wszystkie wywołania do tej nazwy metody/zmiennej. Nie musisz zmieniać ich jeden po drugim, co sprawi, że twój kod będzie podatny na błędy/awarie.
Jeśli chcesz utworzyć metody getter/setter dla wszystkich swoich zmiennych prywatnych, po prostu użyj „create getter/setter”, a IDE automatycznie utworzy metody dla ciebie.

API są poręczne

„CURRENT SOFTWARE PROJECTS SPEND ABOUT 40 TO 50 PERCENT OF THEIR EFFECORT ON AVOIDABLE REWORK”

Przed zaimplementowaniem metody upewnij się, że nie są one dostępne do użycia. Nie musisz kodować, jeśli możesz po prostu zaimportować funkcjonalność. To czyni życie dewelopera super łatwym.
Słynne powiedzenie brzmi „Nie wymyślaj koła na nowo” i jest prawdziwe w wielu przypadkach. Jednak zawsze należy rozważyć implikacje importowania biblioteki, szczególnie jeśli jest to strona trzecia. Pomijając możliwe problemy licencyjne, możesz po prostu nadymać swoją bazę kodu. Jeśli wszystko, czego potrzebujesz, to metoda, która konwertuje temperatury, nie musisz importować biblioteki, która robi to i sto innych rzeczy.

Pair programming/code review

„PEER REVIEWS CATCH 60 PERCENT OF THE DEFECTS”

Te są bardzo pomocne, jeśli chodzi o refaktoryzację twojego kodu. Inni mogą zobaczyć lepszą implementację, aby zoptymalizować twój kod lub po prostu sprawić, że twój kod będzie bardziej elegancki. Zapewnia to również, że programiści przestrzegają standardów, a praca jest podwójnie sprawdzana. Oprócz tego wszystkiego, jest to wspaniały sposób dla programistów, aby uczyć się od siebie nawzajem.

BACKUP I ZAPISUJ SWOJĄ PRACĘ CZĘSTO

Dość powiedziane. Padnięta bateria, przerwa w dostawie prądu, błąd w oprogramowaniu, pożar, katastrofa nuklearna – wszystko to może spowodować utratę danych. Upewnienie się, że często zapisujesz i tworzysz kopie zapasowe swojego kodu w jakimś systemie kontroli wersji jest prostym sposobem na zapewnienie, że twój kod pozostanie bezpieczny.

Standardy kodowania i najlepsze praktyki to ogromny temat – taki, który może być kontynuowany przez wiele stron. W rzeczywistości, jeśli kiedykolwiek zechcesz przeczytać o standardach kodowania w Javie, Oracle ma właśnie to. Zastosowanie tych standardów i praktyk różni się również w zależności od zastosowania – czy pracujesz nad ogromnym projektem korporacyjnym, czy pomagasz młodszemu bratu w odrabianiu pracy domowej. W oparciu o wiele czynników, ostatecznie to od Ciebie zależy, czy kod, który tworzysz, jest dobrym kodem.

Zrzeczenie się odpowiedzialności: Wszelkie poglądy i opinie przedstawione w tym wpisie na blogu są wyłącznie poglądami autora i niekoniecznie reprezentują poglądy i opinie Aversan Inc.

.