Tomasz Kowalczyk

…pisanie_kodu, PisanieKodu, sPisanieKodu - wiele różnych sposobów, na zapisanie tych samych treści, i co z tego wynika.

Każdy programista ma swój własny, wypracowany przez lata sposób pisania kodu, stawiania nawiasów, przecinków, kropek i wielu innych elementów języka formalnego. Jeden wstawia dwie spacje na początku każdej linii, a inny tabulator. Jeden pisze kod wstawiając co chwila nowe linie, drugi uważa taki styl za marnotrawstwo miejsca na ekranie. Wniosek, który można wysnuć na podstawie takich obserwacji jest prosty.

Nie tylko umiejętności, ale i sposób pisania definiują jakość osoby o tak znamiennej profesji. Teoretycznie może się wydawać, że nie ma problemu, ponieważ jak ktoś zna swój fach, to i nieczytelny kod nie utrudni mu sprawy, zgodnie z popularnym przysłowiem, że “złej baletnicy to i…”. W praktyce jednak nie jest już tak różowo, bowiem z biegiem czasu człowiek przyzwyczaja się do swojego stylu pisania podobnie jak do tego, że jest prawo / leworęczny. Zmiana sposobu zapisu owszem, jest możliwa, podobnie, jak przeuczenie się z leworęczności na praworęczność, ale na pewno nie jest to rzecz prosta. Sam, jako dziecko [podobno] zostałem w ten sposób “zmieniony”, więc jakby co służę dowodem. ;] Czytanie kodu napisanego przez inną osobę może nastręczyć wielu problemów ze zrozumieniem, jako, że oprócz rozumienia sensu programu trzeba “na żywo” przerabiać w myślach formatowanie tekstu. Potencjalny “koder” będzie miał niemały orzech do zgryzienia w przypadku, gdy kod będzie napisany w konwencji innej, niż jego własna. Zadanie może urosnąć do rangi niemożliwego, jeżeli przy tym kod będzie napisany po prostu źle w sensie optymalności lub poprawności składniowej. Przykładowa różnica w dwóch zapisach języka C[++]:

potrafi skutecznie utrudnić interpretację zapisanych informacji. Osobiście uważam pierwszy sposób za czytelniejszy, ale na pewno istnieje osoba, dla której ten zapis jest całkowicie nieczytelny, a drugi jest w sam raz.

Większość programistów styl pisania przejęła od swoich “mistrzów”, czyli nauczycieli informatyki lub profesorów na studiach dlatego ich sposób pisania jest “w miarę” zunifikowany. Zaznaczyłem “w miarę”, ponieważ czasem dodają oni od siebie jakieś elementy według nich usprawniające czytelność, co tworzy nowy, zupełnie z niczym niezwiązany styl. Inni zaś wypracowali swój sposób zapisu poprzez własną naukę lub obserwację kodu z którym mieli styczność na etapie tworzenia swoich pierwszych “dzieł”.

Zgoła innym problemem jest sposób nazywania zmiennych. Jest kilka ogólnych konwencji, ale mieszanie ich powoduje zamęt i kolejne utrudnienia w zrozumieniu kodu. Celem informacji, wyróżniamy m.in.:

• notację węgierską, sposób nazywania zmiennych tak, aby bez zaglądania do deklaracji można było stwierdzić jakiego jest typu:
  • sZmienna - string
  • oZmienna - obiekt
  • bZmienna - bool, wartość logiczna
  • iZmienna - int, liczba całkowita
• styl “wielbłądzi”, tzw. CamelStyle, którego głównym zadaniem jest łatwość identyfikacji przeznaczenia zmiennej. Tutaj są też 2 sposoby - albo nazywamy zmienną od razu z dużej litery, albo pierwszy wyraz pozostawiamy jako małą literę:
  • numerArtykulu
  • TablicaZmiennych
• tzw. styl mySQL, czyli oddzielanie kolejnych wyrazów w nazwie zmiennej znakiem podkreślenia - ‘_’. Cała nazwa pisana jest z małej litery:
  • numer_artykulu
  • zmienne_globalne_strony

Oczywiście istnieją inne, ale te są chyba najpopularniejsze. I tutaj, tak jak przy formatowaniu tekstu należy pamiętać, aby trzymać się jednej konwencji.Mieszanie tych stylów, szczególnie szerokich [jak mySQL] z węższymi [CamelStyle, notacja węgierska] może skutecznie utrudnić to, co w założeniu miało pomagać. Celem niniejszego artykułu nie jest w żadnym wypadku krytyka jakiegokolwiek stylu kodowania poza “jedynym, własnym, najlepszym”. Nie jest nim także wskazanie, konwencji w jakiej należy pisać kod tak, aby był czytelny dla każdego, zarówno początkującego, jak i zaawansowanego programisty. Tworząc go miałem na uwadze wskazanie na fakt, że tak pozornie błaha i nic nieznacząca sprawa potrafi poważnie utrudnić proces programowania, nawet względnie prostych programów. Dlatego gdy programujesz, pamiętaj, że kod, który właśnie piszesz może się komuś, nawet Tobie, przydać w przyszłości. Często jest tak, że tworząc nową rzecz przypominasz sobie, że “coś takiego, to ja już robiłem”. Wtedy zaglądasz do starego projektu i paradoksalnie -  nic z niego nie rozumiesz. Wracanie do starego kodu to rzecz [moim zdaniem] bardzo nieprzyjemna, a można ją sobie jeszcze bardziej utrudnić pisząc w sposób niezrozumiały. Pisz czytelnie i zgodnie z wypracowanym lub przejętym wcześniej stylem, aby kiedyś, gdy znowu go zobaczysz, móc wykorzystać jego pomysł lub fragment. I jeszcze jedno - jeżeli tworzysz projekt w grupie, to konformizm w kwestii formatowania kodu jest jak najbardziej wskazany. Nie ma nic bardziej utrudniającego życie,  [oprócz braku kompetencji, oczywiście] niż żmudne wczytywanie się w wypociny kolegi z grupy, “bo on ma inny styl”. Dlatego zanim zaczniecie tworzyć, ustalcie, jakich zmiennych używacie, jak zostaną nazwane i do czego będą służyły.

Mam nadzieję, że informacje zawarte w niniejszym artykule pomogą Tobie, internauto w jakikolwiek sposób ułatwić sobie pracę i, co najważniejsze, życie. Jeżeli artykuł ci się spodobał - dodaj komentarz i powiedz, co uważasz za najbardziej pomocne. Jeżeli nie - tym bardziej powiedz mi co w nim Twoim zdaniem należy poprawić.

Z góry dzięki.Tomasz P.F. Kowalczyk alias Tommy The Thunderer.