Witaj, Gościu O nas | Kontakt | Mapa
Wortal Forum PHPEdia.pl Planeta Kubek IRC Przetestuj się!
Wyszukiwarka

Wyszukiwarka

Aby odnaleźć interesujące Cię informacje wpisz poniżej szukane frazy:
Logowanie

Logowanie

Zaloguj się aby zobaczyć swój profil:

Powszechne standardy kodowania - Czy zawsze pożyteczne?

Celem tego artykułu nie jest negowanie przydatności powszechnie używanych standardów kodowania. Nie jest to także ich przegląd. Chciałbym raczej pokazać, że w pewnych sytuacjach naginanie niektórych reguł może przynieść wymierne korzyści.

Formatowanie kodu źródłowego - wcięcia

Najczęściej spotykamy się z kodem, który wygląda podobnie jak ten przedstawiony poniżej:

Rysunek 1 - najczęściej stosowany rodzaj wcięć

Teoretycznie wszystko wygląda w porządku, ale spójrzmy "z lotu ptaka" na bardziej rozbudowany rzeczywisty kod, który jest zbudowany w ten sposób:

Rysunek 2 - powszechnie stosowane wcięcia "z lotu ptaka"

Czy jesteś w stanie bez większego wysiłku stwierdzić gdzie zaczyna i kończy się dany blok instrukcji? Często musimy wzrokowo prześledzić fragment kodu szukając zakończenia interesującego nas bloku. Najczęściej tak jak w powyższym przykładzie wewnątrz bloku znajdują się inne instrukcje blokowe. Załóżmy teraz, że przeglądasz kod źródłowy, który napisałeś rok temu lub został napisany przez innego programistę. Nie pamiętasz lub nie wiesz jakie fragmenty kodu są odpowiedzialne za działanie, które w danym momencie cię interesuje. Prawdopodobnie będziesz musiał prześledzić wzrokiem cały plik źródłowy. W przypadku gdy masz plik źródłowy wielkości rzędu kilkuset linijek, zadanie to może stać się mało przyjemne. Ale teraz wyobraź sobie, że twój kod został zbudowany podobnie jak ten poniżej:

Rysunek 3 - głębokie wcięcia

Konstrukcja raczej rzadko spotykana, ale spójrzmy na nią "z lotu ptaka". Poniżej bardziej rozbudowany rzeczywisty kod, który został napisany w ten sposób:

Rysunek 4 - głębokie wcięcia "z lotu ptaka"

Na pierwszy rzut oka można stwierdzić, ze mamy dwa podstawowe bloki instrukcji, z czego pierwszy jest bardziej rozbudowany i zawiera zagnieżdżone dwa bloki. Gdy przeglądając taki plik, stwierdzisz, że pierwszy blok cię nie interesuje, z łatwością przechodzisz wzrokiem do następnego bloku.

Używanie zaproponowanego formatowania, czyli głębokich wcięć, niesie ze sobą pewne ryzyko znacznego zwiększenia szerokości kodu. Praktycznie w zasięgu wzroku i edytora zmieszczą się maksymalnie 3 poziomy zagnieżdżenia. Jak do tego nie dopuścić? Jeśli mamy rzeczywiście dużo zagnieżdżeń, znaczy to że najprawdopodobniej nasz kod nie jest dobrze zhermetyzowany - czyli opakowany w klasy i funkcje. Są one stosowane nie tylko dlatego, żeby nie pisać kilkakrotnie tego samego kodu. Są stosowane również po to aby wyodrębnić i nazwać fragmenty kodu wykonujące określone zadania. Powoduje to, że kod staje się o wiele bardziej czytelny, zarówno dla nas samych jak i innych programistów.

Nazewnictwo

Powszechnie uznaną praktyką jest stosowanie anglojęzycznych nazw dla funkcji, klas, zmiennych itp. Jednak odejście od tej zasady może przynieść pewne korzyści. Dlaczego? Elementy, którym nadamy nazwy w ojczystym języku w naturalny sposób wyróżniają się. Dzięki temu od razu wiemy, że funkcja o nazwie RysujSzescian() jest naszą własną funkcją i nie pochodzi z jakieś biblioteki graficznej lub nie jest jakąś mało znaną funkcją dostarczaną bezpośrednio przez PHP. Działa to trochę podobnie jak kolorowanie składni. Spójrzmy na poniższe dwa przykładowe kody źródłowe. W sensie logicznym są takie same. Różnią się tylko tym, że w jednym użyto angielskich nazw własnych, a w drugim polskich.

Rysunek 5 - kod z angielskimi nazwami funkcji i zmiennych
Rysunek 6 - kod z polskimi nazwami funkcji i zmiennych

Unifikacja nazw kolumn tabeli

Zazwyczaj, gdy tworzysz nową tabelę w bazie danych, kolumnom nadajesz takie nazwy, aby w pełni odzwierciedlały ich specyfikę. Dla przykładu, gdy tworzysz katalog firm, prawdopodobnie utworzysz tabelkę z kolumnami podobnymi do poniższych:

Po stworzeniu tabelki prawdopodobnie utworzysz formatkę z listą firm i możliwością wyszukiwania względem wszystkich kolumn (z wyjątkiem kolumny idFirmy). Najprawdopodobniej w części przeznaczonej dla osób z odpowiednimi uprawnieniami zaprogramujesz możliwość dodawania, edycji czy też usuwania firmy. To wszystko daje już całkiem dużo pracy. Powiedzmy że udało ci się to wszystko zrobić. Teraz zabierasz się za nowe zadanie. Chcesz stworzyć książkę adresową, gdzie przechowywane były by dane prywatnych osób albo pracowników. Prawdopodobnie stworzysz tabelkę z kolumnami w rodzaju:

Podobnie jak w przypadku katalogu z firmami tworzysz listę z wyszukiwarką, możliwością dodawania, edycji oraz usuwania. Bardzo prawdopodobne, że skorzystasz z fragmentów kodu, który napisałeś przy tworzeniu katalogu firm. Dlatego aby jak najmniej było do zmieniania, już na etapie tworzenia pierwszej tabeli warto zastosować dość ogólnikowe nazwy kolumn. Na przykład zarówno katalog firm jak i książka adresowa pracowników mogły by mieć takie kolumny:

Oczywiście w prawdziwym projekcie nie zawsze da się ujednolicić wszystkie nazwy kolumn, ale im większe podobieństwo w strukturze tabel tym mniej mamy pracy. Oszczędzamy swój czas już na etapie tworzenia samej tabeli, ponieważ po utworzeniu pierwszej tabelki, możemy wyeksportować ją do zapytania w postaci CREATE TABLE i zmienić różniące się elementy. W przypadku z powyższego przykładu w zapytaniu zmieni się jedynie nazwa tabeli.

Podsumowanie

Pisząc kod powinniśmy pamiętać o tym, że prędzej czy później kiedyś będziemy musieli do niego zajrzeć w celu dokonania zmian lub rozbudowania. Czytelność kodu ma bardzo duże znaczenie - od niej zależy jak długo zajmie nam rozszyfrowanie o co nim chodzi.

W tym niewielkim artykule pokazałem kilka sprawdzonych przeze mnie metod kodowania. Oczywiście każdy programista czy też grupa programistów ma ustalone i sprawdzone swoje sposoby pisania kodu, nazywania zmiennych i funkcji. Myślę jednak, że warto przeanalizować powyższe wskazówki, być może okażą ci się przydatne.

Informacje na podobny temat:
Wasze opinie
Wszystkie opinie uzytkowników: (8)
wcięcia
Wtorek 01 Grudzień 2009 7:56:34 pm - pp-layouts <jim_at_valis.net.pl>

Z tymi wcięciami to nie do końca tak, że można pozbyć się zagnieżdżenia, jeśli wydzieli się bloki kodu. Ja często stosuję np foreach (...) if (...) foreach () itd. Tego nie da się skrócić. Ani rozbić. Można na siłę, ale otrzymamy nie tylko niepotrzebnie rozwlekły i mniej czytelny kod, ale także wolniejszy, bo wywoływanie funkcji i metod kosztuje czas. Z wcięciami chyba najważniejsze jest, żeby trzymać się 1 standardu. Ja używam 2 spacji. Wszędzie. Zawsze. Dzięki temu zawsze widać na jakim poziomie zagnieżdżenia jest dany fragment kodu. Dobre edytory pokazują pionowe lijnijki gdzie trzeba. Ważne żeby nie mieszać spacji z tabami. Bo w edytorach da się zmienić szerokość taba - wtedy źle napisany kod się rozjeżdża, a dobrze napisany nadal zachowuje czytelność.

W JS wcięcia są jeszcze bardziej potrzebne, bo jako parametry funkcji często podstawia się funkcje albo rozbudowane obiekty. A w JS szybkość jest kluczowa, nie chcemy przecież żeby nasza aplikacja zamuliła komuś kompa. Jeśli coś odpala się przy każdym naciśnięciu klawisza, musi być zoptymalizowane.

Używam monitora 16x10, czcionki bodajże 10px, a mimo wszystko ledwo mieszczę kod na szerokość. Bo przecież nie wykorzystuję całego monitora na edytor, po lewej mam zwykle drzewko klas albo plików.

Co do nazw polskich, to powiem tak: nazwy polskie tylko z UTF-8. A z UTF-8 wszędzie są nadal problemy. O ile nad językami programowania pracują międzynarodowe społeczności - dlatego UTF tam po prostu działa, to narzędzia programistyczne (edytory, IDE) piszą amerykańskie firmy, dla których litera to ASCII i koniec. A polski bez polskich liter? Toż to pokraczne. Dlatego lepsze angielskie.

Spójność
Wtorek 03 Marzec 2009 11:57:24 am - marcin_kivrin <marcin_at_kivrin.org>

Witam!

Zaintrygował mnie ten artykuł. Więc postanowiłem odnieść się do dwóch spraw.
Po pierwsze wcięcia. Monitory są dziś szerokie, więc zwiększenie wcięć ma jakiś sens, ale moim zdaniem z lekka przesadna jest propozycja Autora. Jak dla mnie gdy funkcja robi się zbyt długa by ją łatwo przeanalizować, to coś z nią jest nie tak. Może warto było by rozbić ja na ileś mniejszych funkcji. Takie działanie ma głęboki sens i o wiele łatwiej czyta się taki kod, nie zastąpią go "hiperwcięcia". Ktoś kiedyś wymyślił funkcje, więc korzystajmy z nich!

Druga sprawa to spójność, nie wyobrażam sobie pisania nazw funkcji i zmiennych po polsku. Taki kod gdzie łączymy nazwy polskie z angielskimi jest ładnie to ujmując: nie estetyczny. Estetyka kodu wbrew pozorom jest bardzo ważnym czynnikiem wpływającym na dalszy jego rozwój. Ta u waga tyczy się także poprzedniego punktu. Jeśli jakaś funkcja jest nad wyraz długa i nie czytelna to też nie przejdzie przez kryterium estetyczne.

W PHP i tak już mamy wystarczający galimatias z nazewnictwem metod i funkcji, raz wielbłąd raz podkreślnik, nie dokładajmy do tego jeszcze polskich nazwa.

Pozdrawiam
MM

Odejście od standardów czy własne standardy?
Wtorek 10 Luty 2009 7:25:15 pm - bigzbig

Każdy z czasem dopracowuje się własnych standardów - mniej lub bardziej koherentnych ze standardami powszechnie uznanym.

Pomysł z wcięciami uznaję za ciekawy bo wszystko co egzotyczne mnie ciekawi.

Polskie nazwy funkcji i zmiennych. Co za różnica czy to jest funkcja wbudowana czy napisana przez Ciebie. Większość funkcji w moich aplikacjach nie jest mojego autorstwa bo używam frameworków, wyspecjalizowanych skryptów, aplikacji lub bibliotek - jak zwał tak zwał. Jakoś wyróżnianie moich własnych wypocin nigdy nie było mi potrzebne.

Opisany przez autora sposób nadawania nazw kolumnom tabeli w BD to się nawet do tworzenia bloga nie nadaje. Takie skróty prędko kończą się niepotrzebnymi komplikacjami i zamiast zyskiwać na czasie trzeba wszystko odkręcać.

Szczególnie początkującym programistom polecam zapoznanie się z wypracowanymi przez doświadczonych programistów standardami i trzymanie się ich przynajmniej przez kilka projektów.

Tak na marginesie - poprzedzanie nazw zmiennych literkami oznaczającymi typ zmiennej to tzw. notacja węgierska.

opinia
Niedziela 01 Luty 2009 7:15:53 pm - rzymek01

Artykuł kończy się tam, gdzie powinien się właściwie zacząć :P

cytat @phpion
"Pierwszy screenshot przedstawia kod sformatowany w sposób, z którym (wg autora) spotykamy się najczęściej. Ja ani razu nie widziałem takiego formatowania (chodzi mi o umiejscowienie klamer w nowej linii i z tabulatorem)."

ja widziałem kod z umiejscowaniem klamer w nowej lnii ale bez tabulatora (i dla mnie jest to wygodny sposób, bo widzimy gdzie dany blok się zaczyna i kończy)

Pozdrawiam - rzymek01!

Wcinanie
Wtorek 06 Styczeń 2009 2:30:58 pm - daniel1302

Przecież wcinanie tekstu da się ustalić w 99% edytorów jaki ma być Szerokośc TAB, szerokość wcięcia itp. A im więcej TABOW tym wiecej KB

IMHO
Sobota 03 Styczeń 2009 3:59:10 pm - legorek

Odnośnie wcięć, nie widzę sensu w korzystaniu z tej metody. Każde bardziej zaawansowane IDE posiada swój sposób oznaczania i nawigacji pomiędzy blokami kodu, można się połapać bez problemu. Nikt nie pisze 1000 linijek w notatniku.

Odnośnie polskiego nazewnictwa. I znów wszystko rozbija się o IDE. Najeżdżam myszką na funkcję i już wszystko o niej wiem. Dlaczego funkcje zdefiniowane przez programistę mają się wyróżniać? Ważne żeby było wiadomo do czego służą. Warto więc pisać dobrą dokumentację.
Język angielski jest międzynarodowy, dzięki temu, jak pokażesz swój program koledze z USA albo Hiszpanii, będzie wiedział co robi dana funkcja. Pisząc po Polsku tracisz tą możliwość. Polskie nazwy nie zawsze będą odpowiednie. Powiedzmy ze masz funkcje: do_me_a_favour(); Po polsku to bedzie zrob_mi_laske().
Jeszcze jedna rzecz: według mnie dobrą praktyką przy nazewnictwie funkcji jest forma obiektMetoda().

Czyli:

SzescianRysuj();
SzescianObliczObjetosc();
SzescianObliczPowierzchnie();

KulaRysuj();
KulaObliczObjetosc();
KulaObliczPowierzchnie();

Zamiast

RysujSzescian();
RysujKule();

ObliczObjetoscSzescian();
ObliczObjetoscKula();

ObliczPowierzchnieSzescian();
ObliczPowierzchnieKula();

Dlaczego? Bo od razu wiesz na czym operuje funkcja. Programowanie polega na tym że masz już dane (Sześcian) a potem wykonujesz na nich operacje (ObliczPowierzchnie). Rzadko kiedy jest tak, że najpierw zastanawiasz się co będziesz liczył, a potem jakie będą dane na wejściu. Kolejny plus: początkującemu programiście będzie potem łatwiej przejść na programowanie obiektowe

Odnośnie unifikacji nazw pól w tabelach. Dobrą według mnie praktykę zademonstruje na przykładzie prostej tabli forum:

Topics: id, name, date
Posts: id, topicsId, usersId, text, date
Users: id, name, password, exampleTableSomeField
ExampleTable: someField, otherField

Stosując takie nazwy jak np topicsId od razu widzimy, że tabele są połączone. I tutaj radzę stosować metodę: obiektWłaściwość (czyli usersId a nie idUsers).

Na koniec jeszcze o nazwach zmiennych, bo autor w ogóle nie wspomniał tutaj o tym. Nie będę mówił, żeby nadawać im sensowne nazwy, bo to chyba każdy wie. Nie wspomnę żeby nazywać jest zgodnie z metodą obiektWłaściwość ($userName, $userId) Natomiast dobrą praktyką według mnie jest określanie jakiego typu jest zmienna, szczególnie jeśli nie wynika to z jej nazwy. Jak to zrobić? Przez dodanie przedrostka:
a - dla tablic
s - dla stringów
itd...
Wtedy wiem, że np. $aKeywords zawiera słowa kluczowe w formie tablicy a $sKeywords, są prawdopodobnie oddzielone przecinkami.

Dziękuję za uwagę :)

Errata
Sobota 03 Styczeń 2009 1:58:12 pm - scanner <scanner_at_poczta.php.pl>

Obrazek nr 6 rzeczywiście był błędny, za co przepraszam.

:|
Sobota 03 Styczeń 2009 11:06:56 am - phpion

Moim zdaniem artykuł na bardzo niskim poziomie merytorycznym.

Pierwszy screenshot przedstawia kod sformatowany w sposób, z którym (wg autora) spotykamy się najczęściej. Ja ani razu nie widziałem takiego formatowania (chodzi mi o umiejscowienie klamer w nowej linii i z tabulatorem).

Patrzenie na kod z lotu ptaka - któż tak patrzy? No ludzie! Równie dobrze możnaby dać kategorię "patrzenie do góry nogami".

Argument o tym, że jeżeli nasz kod ma dużo wcięć (powyżej 3?) to jest źle napisany. Parodia.

Moim zdaniem równie wątpliwy jest pomysł pisania w języku ojczystym. Dla mnie wygodniej i naturalniej pisze się nazwy klas, metod, funkcji, zmiennych etc. po angielsku.

Ostatni przykład dotyczy nazw kolumn w tabelach. Kolejna głupota? Jedyne co mi się podoba to zmiana idOsoby na Id ale dlaczego u licha imię i nazwisko pracownika ma być zapisane w jednej kolumnie Nazwa? Równie dobrze można było stworzyć tylko 2 kolumny: Id, Dane i do tej drugiej pakować wszystko, co jest związane z pracownikiem. Nie czepiam się kolumny Adres bo rozumiem, że to przykład i nie było sensu rozbijać tego w rzeczywisty sposób.

Moim skromnym zdaniem ten artykuł to porażka.

PS: chyba rysunek 6 to nie ten, który powinien być ;)

Mentax.pl    NQ.pl- serwery z dodatkiem świętego spokoju...   
O nas | Kontakt | Mapa serwisu
Copyright (c) 2003-2017 php.pl    Wszystkie prawa zastrzeżone    Powered by eZ publish Content Management System eZ publish Content Management System