Human Creativity

Funkcjonalne dzieło sztuki zamknięte w nawiasach – kody źródłowe

Autor: agmakonts Data: Luty 28, 2009

fot: kleinman - flickr

fot: kleinman - flickr

Przejrzyście, konsekwentnie i rozważnie  napisany kod naprawdę jest czymś pięknym dla oczu programisty. Niestety spora część osób które tworzą swoje pierwsze  aplikacje czy to internetowe czy desktop-owe już nie te do szuflady ale w zamyśle przynajmniej przeznaczone do puszczenia w świat tworzą kod bez namysłu i przynajmniej ogólnego, wcześniejszego rozplanowania. Oczywiście umiejętności planowania i ponownego użycia kodu przychodzą z czasem ale czemu nie uczynić tego procesu szybszym i oszczędzić sobie wiele czasu i nerwów na pisaniu po raz 30 tej samej aplikacji tylko dlatego że było to szybsze od modernizacji.

Sam gdy zaczynałem programować nawet w obiektowych językach pisałem kod liniowo i nie zastanawiałem się za bardzo nad tym czy podobny fragment napisałem już wcześniej kilka razy. Pamiętam jak pisałem pierwszą większą rzecz w php, rozbudowane bazy danych itp. a kod całego serwisu leciał ciurkiem w jednym pliku. Dla tych co jeszcze żyją w złudzeniu że jest to wygodne bo ma się wszystko pod ręką i nie trzeba skakać po plikach mam tylko dwa słowa: NIE JEST.

Jedną z najważniejszych rzeczy w pisaniu schludnego i zrozumiałego kodu jest konsekwentne, intuicyjne oraz dokładne nazewnictwo. Tyczy się to zarówno nazw plików, klas, funkcji, zmiennych oraz w przypadku stron selektorów css. Jeśli rozdrabniasz system na komponenty i główne systemy oraz trzymasz ich kody w osobnych plikach najlepiej nazywaj je tak by od razu było wiadomo o co chodzi np. plik oraz komponent odpowiedzialny za łączenie z bazą danych w nim zawarty oznacz jako sterownik_bazy i sterownik_bazy.komponent.php, a kod odpowiedzialny za ładowanie poszczególnych klas czy funkcji jako loader.system.php. Raz że takie nazewnictwo ułatwi Ci wprowadzanie zmian oraz umożliwi automatyzacje wielu procesów, możesz na przykład automatycznie ładować zawartość wszystkich plików o rozszerzeniu komponent.php z konkretnego folderu. Podobnie możesz wykorzystać np. w php nazwy klas by były identyczne jak nazwy plików a potem wraz z automatycznym includem od razu tworzyć obiekty nie martwiąc się o nic i wszystko zostawiając w rekach skryptu. Pomijając już zalety odpowiedniego nazwenictwa przy automatyzacji różnych procesów ma ono także wiele zalet dla samego programisty. Spora aplikacja ma czasem setki zmiennych i jeśli mają nazwy w stylu “a” albo “zmienna1″ po pewnym czasie bez przestudiowania towarzyszącego im kod nie będziesz wiedział do czego służą i co przechowują. Tworzenia zmiennych o dłuższych nazwach może z początku wydawać się meczące i niewygodne ale po pewnym czasie docenisz te 5 sekund poświęconych na dodanie 10 znaków do każdej nazwy. W całym nazewnictwie, od klas aż po zmienne trzymaj się także jednolitego systemu, albo wszystko małymi literami z “_” pomiędzy wyrazami albo każdy wyraz zaczynaj od wielkiej litery i nie rób odstępu między nimi. Wybór należy do Ciebie, rób tak by było Ci wygodnie ale za wszelką cenę bądź konsekwentny w tym jak nazywasz poszczególne elementy programu. Staraj się tez nie używać znaków nie łacińskich, co prawda sporo języków je akceptuje ale dla pewności nie ma sensu ryzykować.

Niesamowicie przydatną choć tak często pomijaną zaletą zdecydowanej większości języków są komentarze. Jeśli wydaje Ci się że skoro piszesz coś tylko dla siebie i nikt nie będzie współtworzył kodu więc nie ma potrzeby użycia komentarzy i opisywania skrupulatnie każdego kawałka kodu jesteś w błędzie. Gdy po miesiącu spojrzysz do kodu na parę tysięcy linii i nic nie będziesz miał opisane wiele czasu zajmie Ci znalezienie odpowiedniego elementu i rozgryzienie jak działa konkretny fragment kodu.

Formatowanie tekstu to nie tylko zmiana czcionki w wordzie. Gdy piszesz kod aplikacji dobre jego sformatowanie naprawdę daje sporo czytelności. Stosuj wcięcia tak by ukazać hierarchie w kodzie.

Absolutnie najgorszą rzeczą jaką można zrobić zwłaszcza w większych aplikacjach jest mieszanie warstw widoku oraz logiki. Nigdy nie mieszaj tego co wyświetlasz użytkownikowi oraz tego co obliczy co mu wyświetlić. Konsekwencje takiego kodowania widać chyba najwyraźniej w aplikacjach webowych gdy mieszasz kod html-a i np. php. Do przekazywania danych pomiędzy warstwami używaj czegokolwiek, może to być klasa, zmienne, gotowy system szablonów, choćby poczta polska ale nigdy nie mieszaj tego. Rozgraniczenie warstw daje Ci tą przewagę że zmiana interfejsu użytkownika nie ma nic wspólnego z działaniem aplikacji tak samo jak zmiana algorytmu nie wymaga ingerencji w interfejs.

Stworzenie kodu który będzie czytelny i przyjazny dla programisty zajmuje o wiele więcej czasu niż pisanie bez zachowania zasad które opisałem. Nie jest to czas niewiele dłuższy, jest czasem nawet 10 razy dłuższy i cały proces bardziej męczący jednak przy rozwijaniu aplikacji już przy pierwszym uaktualnieniu zwróci Ci się on z olbrzymią nadwyżką.

Dodaj komentarz

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Zmień )

Twitter picture

You are commenting using your Twitter account. Log Out / Zmień )

Facebook photo

You are commenting using your Facebook account. Log Out / Zmień )

Connecting to %s

Follow

Otrzymuj każdy nowy wpis na swoją skrzynkę e-mail.