Przynoszę wam tedy jedno i najważniejsze przykazanie:
Dbaj o kod, nigdy nie wiesz, kiedy będziesz musiał do niego wrócić. Praca programisty polega na rozwijaniu oprogramowania, a nie na jego ciągłym przepisywaniu od zera.
Pisząc program, stosuję ścisłe zasady jego tworzenia. Są miejsca, gdzie czytelniej wyglądają instrukcje warunkowe, są miejsca, gdzie czytelniejsze są przełączniki wyboru. Niektóre zasady są niezmienne. Nie uznaję więcej niż jednego pustego wiersza z rzędu. Nie uznaję operatorów, które nie są poprzedzone spacją i po których spacja nie występuje. Po przecinku wymagam spacji. Klamra otwierająca blok zawsze jest wyrównana do lewej względem wyrażenia warunkowego, do którego jest przypisana. Klamra zamykająca znajduje się na tym samym poziomie wcięcia. Ściśle formatuję nawet zapytania SQL:
$query = " SELECT foo.a, foo.b, baz.c FROM foobar AS foo INNER JOIN bazorg AS baz USING (d) WHERE foo.a > 3 AND baz.c = 'a' ";
Nie twierdzę, że moje zasady są jedynie słuszne. Są spójne i gwarantują mi, że kod jest czytelny do tego stopnia, że mogę szukać interesujących mnie miejsc, przelatując wzrokiem po kodzie podczas ciągłego przewijania. Ma to kolosalne znaczenie przy systemie CMS, gdzie poszczególne moduły liczy się w tysiącach linii.
Niestety, mojego kolegi żadną siłą nie daje się zmusić do dbania o kod. Nie mówię o ścisłym przestrzeganiu moich reguł. Chodzi o utrzymanie jakiegokolwiek standardu. Nic nie szkodzi - jako, że regularnie robię przegląd kodu, każdą okazję wykorzystuję do jego czyszczenia. Łamię długie linie, dodaję spacje po przecinkach i dookoła operatorów, zamieniam indentację ze spacji na tabulatory i usuwam białe znaki z końców wierszy.
Przyświeca mi zasada wyznawana też przez jednostki S.W.A.T. - clean as you go.
Usuwam też brzydkie hacki, które dobrze działają. Wolę przepisać je w poprawny sposób i móc szybko dojść, co dany kawałek kodu robi. Próba zrozumienia czegoś, co przypomina relikty obcej cywilizacji - zwłaszcza, kiedy klient wisi na telefonie i dopytuje o termin zamknięcia poprawek - z pewnością nie należy do przyjemnych.
Ktoś pewnie nazwie to stratą czasu, ale dla mnie to jedyna metoda wspólnej pracy nad większą bazą kodu. Jeśli programista sam nie szanuje swojego kodu, to znaczy, że lekceważąco traktuje swoją pracę. Jeśli ktoś nie lubi swojej pracy, to po co ją wykonywać? Oczywiście, są projekty, które się dziedziczy po script kiddies i tam często zdarza się pisać kod wiele pozostawiający do życzenia, byle wpasował się w otoczenie i nie sugerował, że nad projektem pracował ktoś rozsądny, ale to historia na inną okazję.
Twój kolega stosuje chyba zasadę S.A.S.: Speed, Aggressive, Surprise ;)
> usuwam białe znaki z końców wierszy.
Edytory z KDE mają opcje autoczyszczenia kodu przy zapisywaniu. Nigdy więcej nadmiarowych spacji :)
Każdy sensowny edytor ma taką opcję, a ja w Quancie mam dodatkowo włączone wyświetlanie białych znaków.
A kolega stosuje raczej RAC - Rapid Application Complication.
Truizmy, truizmy, truizmy ….
Gdyby tak jeszcze ktoś się do nich stosował :P
Prawda jest taka, że większość programistów piszę tak, że woła to o pomstę do nieba. Nawet komentarzy nie chce im się pisać, bo "przecież ja rozumiem, o co w tym chodzi".
ps. Ale bardzo mi się podoba twój sposób formatowania zapytań SQL (wielowierszowo) - muszę to u siebie zastosować.
Carstein:
Przy czytelnie napisanym kodzie brak komentarzy nie jest dużym problemem.
Teoretycznie nie, ale czasami lepiej w komentarzu wyjaśnić o co tobie chodziło - w sumie to raczej miałem na myśli pisanie tzw. dokumentacji funkcji w pythonie:
def funkcja():
""" Jestem sobie funkcja i nic nie robie """
pass
Coś w tym stylu
> Każdy sensowny edytor ma taką opcję
A właśnie w NetBeans nie widzę :(
U nas do tego służą komentarze phpDoc:
/**
* Funkcja robi nic
* @param string cokolwiek
* @returns string to samo
*/
function robNic($a)
{
return $a;
}
Rżnięte z java dodajmy :P
Bo Java ma najlepszy format do tego. Podobne systemy istnieją dla większości popularnych języków.
Sama prawda.
Teraz pytanie, kiedy autorzy g… takiego jak np. phpBB to zrozumieją. Na razie tego nie zrobili, co widzę aż nadtwo wyraźnie, przepisując toto. Indeks się już wyświetla.
Jak to ładnie ktoś ujął: ,,Pisz kod tak, jakby osoba, która go po Tobie przejmie była uzbrojonym psychopatą znającym Twój adres.''
Świat byłby lepszy, gdyby powyższa rada wisiała nad biurkiem każdego programisty.
łasica:
Pewnie podobnie jak w eclipse: ctrl-shift-f
Bo w ilu firmach stosuje sie regularne i planowe audyty kodu, w ktorych kazda linijka zatwierdzana jest osobno? Utrudnienie: Motoroli Krakow nie liczymy ;)
+ bonusik (przepraszam, ze tak na raty znowu, ale tlen mi sie konczy):
http://www.extremeprogramming.org/rules/simple.html
http://www.extremeprogramming.org/rules/collective.html
http://www.extremeprogramming.org/rules/refactor.html
ale my tu gadu gadu, a tam Firefoksa 1.5 wypuścili ;)
Zabawne. Cały post poświęcony jedynie składni, podczas gdy tak naprawdę to jest najmniej istotna rzecz: większość tego rodzaju smaczków i tak wykryje edytor.
Chciałem takie coś napisać odnośnie CSSa i jeszcze chyba napiszę. ;) Więc jak coś to nie czepiać się, że kopiuję.
eustachy:
Ja uważam, że składnia jest jednym z najważniejszych elementów kodu. Kiedy otwieram cudzy projekt albo projekt, w którym nie zmieniałem nic od roku, to nie interesuje mnie, jak zaimplementowano algorytmy przeszukiwania stosów. Interesuje mnie jak najszybsze znalezienie właściwego miejsca w kodzie i łatwe poprawienie tego, co mam do poprawienia. Nie chcę przy okazji czytać całego pliku w poszukiwaniu miejsca, gdzie zaszyte zostało zapytanie SQL i potem próba określenia, gdzie umieścić ugly workaround na jeszcze brzydszy hack, który przed poprawkami działał bez zarzutu ze względu na swoje wąziutkie założenia.
Mówisz w poprzednim komentarzu o dwóch kompletnie różnych rzeczach.
Składnia, jako wygląd kodu, istotnie jest istotna, ale, jak powiedziałem, nie ma najmniejszych problemów z automatycznym jej czyszczeniem od lat, zatem przesadą jest poświęcanie jej całej notki, z której implicite wynika, że "zasadami tworzenia" są konwencje nawiasów stawiania klamrowych.
Dobrą rozwijalność (reusability) oprogramowania zapewnia się za pomocą dobrej, niekoniecznie klasowej, abstrakcji, wzorców projektowych i na przykład odpowiednich warstwy abstrakcji.
Nawet najpiękniej poformatowany kod będzie trudny do dalszego rozwoju, gdy spapra się robotę warstwę wyżej.
Niecierpliwe czekam na Biblię Patrysa, of kors z wywalonym w pytę zdjęciem na okładce i mentorskimi wywodami insajd.
W gruncie rzeczy to jednak słaby ten twój nieustający lans :S
omg:
Pamiętaj, że jesteś na blogu, a nie na portalu informacyjnym.
A mi się lans podoba. Nie jest to kolejny blog anonimowego (znanego tylko z ksywy) nudziarza, a notka ozdobiona zakazaną mordą na śmiesznym zdjęciu o wiele lepiej zapada w pamięć :).
Jedyne i słuszne. Żeby jeszcze były stosowane, uhh.
O, nasza baza znów działa.
Dopiero co "wczora z wieczora" miałem dyskusję, którą można skrócić do "rób szybciej, nie dbaj o kod, bo nikt na to nie patrzy - ważne by było".
Chwilę po rozmowie zadzwonił klient i przysłał poprawki..
A ja mam was gdzieś.Ignoranci.
Znajdę milsze blogi
Hm?