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.

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

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.

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!

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

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ę :)

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

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ć ;)