: Standard kodowania

Pary_anime

W wyniku przeprowadzonego głosowania grupa ochotników zaakceptowała propozycję standardy kodowania dla projektów OpenSource.

Prace nad "Standardem..." przebiegały w burzliwej atmosferze. Były długotrwałe dyskusje, przekonywania sie (co tu ukrywac) zażartych kłótniach. Dyskusjom nie było końca. Ostatecznie zdecydowano się poddać projekt Standardu pod głosowanie. [/b] Uznaliśmy, że lepsze jest wrogiem dobrego, a nasze akademickie dyskusje mogą się ciągnąć w nieskończoność. Zawsze można niedociągnięcia poprawić później.

Do głosowania zostali zaproszeni nie tylko uczestnicy dyskusji, ale również inni zwolennicy PHP i Open Source . Głosowanie zakończyło się 20 grudnia 2002, a więc jeszcze przed

Bożym Narodzeniem.

Przyjęty standard jest kompromisem i może uledz dalszym zmianom. Nikt nie zakłada, że został stworzony raz na zawsze, a jego cel to stworzenie konwencji zapisywania kodu.

Jeszcze przed głosowaniem, że osoby wstrzymujące się od głosu nie wpływają na wynik głosowania, ale ich głos wskazuje, że uważają za konieczne rozważenie w przyszłosci zmian w przypadku ewentualnego przyjecia poszczególnych elementów "Standardu...).

Wyniki głosowania w procentach (za / wsztrzymało się / przeciw):

l Po co jakiś standard? ( 76 / 11 / 11 )
lStyl pracy nad projektem ( 75 / 6 / 18 )
lUkład strony ( 41 / 47 / 11 )
lTworzenie nazw ( 56 / 12 / 31 )
lKomentarze ( 37 / 37 / 25 )
lNawiasy i spacje ( 43 / 31 / 25 )
lIstotne warunki co do kodowania PHP ( 82 / 5 / 11 )
lKodowanie PHP na styku z SQL i tablicami ( 75 / 6 / 18 )
lKodowanie baz danych ( 58 / 5 / 35 )
lKodowanie HTML ( 88 / 5 / 5 )

Zgłoszone od dziś propozycje zmian będą mogły być głosowane w poźniejszym czasie.
Dla celów zgłaszania zmian stworzony został temat: Standard kodowania - propozycje zmian i korekt

---

Wkład w powstanie niniejszej standaryzacji wnieśli (układ alfabetyczny):
antyqjon, roodee, Sl@o

Podczas prac nad standaryzacją korzystano z opracowań:
http://utvikler.start.no/code/php_coding_standard.html
http://srparish.net/writings/php_code_standards.html
http://pear.php.net/manual/en/standards.php

W przypadku watpliwosci lub rozbieznosci o wyborze decydowac bedzie sposob zapisu stosowany z manualem PHP.

Duzy wklad w powstanie niniejszego standardu kodowania dla aplikacji PHP na niniejszym forum wniesli uczestnicy grupy dyskusyjnej pl.comp.lang.php oraz liczni goście na forum Skorosze.pl

Po co jakiś standard?

Niniejsze opracowanie opiera się na dyskusji grupy projektowej i jest częścią projektu Open Source. Niniejszym standaryzacja ma system otwarty, może być modyfikowana, rozbudowywana, skracana, etc, Autorzy liczą jednak na informowanie o naniesionych poprawkach w celu aktualizacji niniejszej standaryzacji.

Określenie to ma sprzyjać powstaniu łatwego do przeglądania i modyfikowania kodu PHP jak najblizszego temu podanemu bibli kazdego PHPowca, tj. w manualu PHP. Nie mniej ważnym celem jest konieczność określenie konwencji pisania aplikacji.

Niniejszy standard kodowania jest bliski tradycyjnej unixowej formule kodowania. Jednakże w wielu miejscach zdecydowano się na rozwiązania praktyczne, które stały w sprzeczności z podejściem tradycyjnym. Ale się będą wkurzać )). Od unixowej tradycji wieksza wage ma dla nas manual PHP.

Dlaczego nie warto stosować standaryzacji w oprogramowaniu Open Source?

Standaryzacja to straszna przeszkoda i same kłopoty.

l każdy może zrozumieć napisany przez Ciebie kod i go rozwinąć
A dlaczego ma rozumieć, ty się tak namęczyłeś, a ktoś ma to rozwijać ot tak sobie. A nie lepiej by posiedział nad tym co zrobiłeś dwa razy dłużej i nic nie zrozumiał. l każda standaryzacja jest _nierozwa* i dlatego lepiej nawet samemu jej nie stosować
Dlatego lepiej nie stosować nawet własnego standardu, bo to naprawdę duży fun nie rozumieć nawet samemu co się napisało. To nawet lepsze od krzyżówek, bo możesz spędzić z kilka godzin na coś, co w inny sposób zajęłoby Ci minutę, a na nowo napisać można w godzinę. l standardy krępuje i niszczą kreatywność
Przecież nie ma nic lepszego jak stosować stylu pisania zależnie od własnego nastroju i dać popis weny twórczej. Np. zacząć pisać funkcję otworzyć nawias i w bloku komentarzy opisać ze szczegółami ostatnie spotkanie z kumplami i dziewczynami, gdzieś w środku przypomnieć sobie co się robi więc wtrącić parę argumentów bez przenoszenia tego do innej linii, wrócić do swego literackiego opisu, dając tym popis swojej literackiej elokwencji..
W ten sposób ktoś nie tylko pozna kod twojej aplikacji, ale i dokulturalni się!
l nie ma nic fajniejszego w PHP jak tworzenie własnego standardu do końca życia. Sam kod jest nudny i jego pisanie można zostawić na późniejl Nie ma nic fajniejszego jak robienie tych samych błędów na nowo i na nowo bez końca.
l po co stosować standardy. Przecież wszyscy są tacy sami i myślą tak samo.
l I tak nikt nie stosuje się do standardów

A teraz już serio
Styl pracy nad projektem

Z uwagi na Ustawe o jezyku polskim, aplikacje beda pisane w Polsce w języku polskim, a czesci powstale za granica tlumaczone na język polski. Jednak dla celów upublicznienia równolegle powinna powstawac wersja w jezyku o charakterze miedzynarodowym.

l Podstawowym celem jest stworzenie aplikacji działającej poprawnie, a dopiero w dalszej kolejności dołączenie cech nadzwyczajnych i innych bajerów l Hierarchia ważności (od cech najważniejszych do mniej ważnych): poprawne działanie, bezpieczeństwo, łatwo czytelny kod, łatwość obsługi, łatwość instalacji i dbałość o mały rozmiar, duże możliwości korzystania, moc, cechy i możliwości aplikacjil Wszystkie komponenty powinny być tak projektowane, by pozwalać na ich prosta administrację, czy konfigurację l Większa dbałość o czytelność kody PHP niż kodu HTML. l Dbałość o jak najprostsze i banalne rozwiązania. Czym prostsze i _nierozwa* tym lepsze.

Z uwagi na tworzenie systemu Open Source:

l wszystkie nazwy zmiennych, funkcji, metod, tablic, pol, klas. etc powinny byc pisane w jezyku o charkaterze miedzynarodowym (wskazany: angielski). l komentarze i naglowki w wersji udostepniane jako kolejne wersje aplikacji powinny być podane w jezyku o charakterze miedzynarodowym (wskazany: angielski) - w przypadku wersji lokalnych mogą być podane w lokalnej wersji jezykowej.

Układ strony
Najważniejszym celem standaryzacji jest pisanie czytelnego i zrozumiałego dla innych kodu.

1. Szerokość strony

l Kod PHP (z wyjątkiem wstawek do HTML) musi mieścić się linii 80-o znakowej. l Powyższa zasada nie jest stosowana w przypadku kodu HTML, ale oczywiści przestrzeganie tej zasady jest mile widziane.

2. Wcięcia:

l Standardowo należy używać wcięcia o długości 4 spacji w przypadku kodu PHP i dwie w przypadku kodu HTML.

(To wciąż jest sprawa otwarta, gdyż niektóre standardy zalecają, w związku z edytorem vim, w każdym przypadku dwie, co nie osobiście się bardzo podoba.)
Nie wolno stosować tabulatorów, chyba, że tabulator działa jako forma wpisywania określonej liczby spacji do kodu. Takie możliwości daje chociażby Emacs, gdzie należy ustawić indent-tabs-mode do nil.

Jedynym wyjątkiem jest możliwość wstawienia tabulatora pomiędzy końcem linii kodu, a początkiem komentarza w tym samym wierszu. W przypadku kilku linii komentarza, równe ich ustawienie pozwolą na większą czytelność.

l Jeśli istnieje konieczność złamania wiersza kodu ze względu na kod, to należy tak go złamać, by poniższa cześć kodu była dokładnie poniżej pierwszej zmiennej w wyższym wierszu.

codeDivStart() $rezultat = stworz_uzytkownika ($uzytkownik, $haslo, $nazwisko
                                $telefon, $email);

---

Tworzenie nazw

Nazwy są jednym z kluczowych elementów kodu PHP - sercem aplikacji.
Nazwy powinny opisywać to co nazywają i do czego służą w sposób jak najbardziej jednoznaczny.
Zaleca się unikanie w opisowej części więcej członów niż trzy, gdyż zazwyczaj utrudnia to zrozumienie kodu niż poprawę jego czytelność. Poza tym takie nazwy są bardziej przemyślane i rzadko potrzebują więcej członów niż 3.

Pakiety
Wszystkie, rozdzielane podkreślenie, człony nazwy pakietu powinny być pisane wszystkim dużymi literami.
Np.
codeDivStart() OPEN_SOURCE

Klasy
Klasy powinny być jak najdokładniejszymi ich opisami. Jeśli to możliwe to zaleca się unikanie skrótów. Każdy człon nazwy powinien być pisany z dużej litery, a człony powinny być rozdzielane za pomocą podkreślenia.
Np.
codeDivStart() Logowianie, Logowanie_Uzytkownika, Wprowadzenie_Nowego_Szablonu.

W przypadku korzystania z biblioteki klas, jako prefiksu należy użyć nazwy pakietu.
Np.
codeDivStart() OPEN_SOURCE_Wprowadzenie_Nowego_Szablonu

Funkcje i Metody
System ten nazywany jest "camel caps". Nazwa pochodzi od wyglądu napisu, który przypomina garby wielbłąda. Pierwszy człon nazwy jest pisana z małej litery, a każdy następny wyraz z dużej, a dodatkowo brak jest znaku (spacja to też znak) rozdzielającego. W przypadku funkcji należy stosować (a przynajmniej się zaleca) prefiksów określających nazwę pakietu, z którego pochodzą funkcje, co zapobiegnie kolizji między pakietami.
Np.
codeDivStart() polacz(), pobierzDane(), OPEN_SOURCE_specyfikujPotrzeby()

Zalecane skróty sufiksy
Max - maksymalna możliwa wartość
Cnt - aktualnie zliczona wartość
Key - wartość kluczowa
Np.
OdpowiedziMax - maksymalna liczba możliwych odpowiedzi,
OdpowiedziCnt - aktualna wartość odpowiedzi

Zalecane skróty prefiksów (na początku duże litery! ):

Is - do zadawania pytania, czy cos jest.
Get - w celu pobrania wartości
Set - w celu ustalenia wartości.
Np.
IsOdpowiedz - Czy jest odpowiedź?

l Żaden z członów nie powinien składać się z dużych liter, nawet gdy ten człon jest skrótem, lub powszechnie uznawaną formą zapisu.

Np.
Poprawnie: GetHtmlStatystyka
Niepoprawnie: GetHTMLStatystyka

l W przypadku funkcji w tzw. klasach prywatnych zaleca się je poprzedzać pojedyńczym podkresleniem.

Np.
_sortuj(), _inicjujDrzewko(), $this ->_status

Wartości stałe
Wszystkie człony nazwy powinny być pisane wszystkimi wielkimi literami łączonymi podkreśleniami. W przypadku, gdy wartość ma związek z nazwą klasy/pakietu to jej/jego nazwa powinna być zapisana wielkimi literami.

Zmienne
Wszystkie człony pisane małymi literami i rozdzielone podkreśleniem.

Elementy tablic
Pisane podobnie jak zmienne. Nigdzie nie używaj myślnika "-". Zawsze używaj apostrofów lub cudzysłowów do wyodrębnienia elementów.
codeDivStart() $myarr['foo_bar'] = 'Hello';  //poprawnie
$myarr['foo-bar'] = 'Hello';  //niepoprawnie

Wartości globalne
W razie potrzeby definiowania wartości globalnych ich nazwa powinna być poprzedzona prefiksem w postaci pojedynczego podkreśleniem, nazwy pakietu oraz kolejnego podkreślenia.
Np.
codeDivStart() $_OPEN_SOURCE_jaki_ladny_jest_swiat

Wartości predefiniowane
Takie wartości jak true, false, null powinny być pisane z małej litery.

Nazwy w bazach danych SQL

klucz podstawowy

l Każda tabela musi mieć ustawiony serial index jako jej klucz podstawowy (primary key), a w nazwie powinien zawierać człon id.

Nazwy tabel

l Nazwami tabel nie mogą być samodzielnie (tzn. jako jedyne człony, bez prefiksów, etc) słowa zarezerwowane dla SQL, tj.:

codeDivStart() abort add all allocate alter analyze and any are as asc assertion at authorization avg begin between binary bit bit_length both by cascade cascaded case cast catalog char character character_length char_length check close cluster coalesce collate collation column commit connect connection constraint continue convert copy corresponding count create cross current current_date current_session current_time current_timestamp current_user cursor date datetime deallocate dec decimal declare default delete desc describe descriptor diagnostics disconnect distinct do domain drop else end escape except exception exec execute exists explain extend external extract false fetch first float for foreign found from full get global go goto grant group having identity in indicator inner inout input insert intersect interval into is join last leading left like listen load local lock lower max min module move names national natural nchar new no none not notify null nullif numeric octet_length offset on open or order out outer output overlaps partial position precision prepare preserve primary privileges procedure public references reset revoke right rollback rows schema section select session session_user set setof show size some sql sqlcode sqlerror sqlstate substring sum system_user table temporary then timespan to trailing transaction translate translation trim true union unique unknown unlisten until update upper usage user using vacuum value values varchar varying verbose view when whenever where with without work write

l Nazwy tablel są zapisane w całości małymi literami, a poszczególne słowa rozdzielone są podkreśleniami
l Nazwy tabel są podawane w liczbie mnogiej zgodnie z tym co zawieraja, tj. zawsze należy pisac uzytkownicy zamiast uzytkownik

.

Nazwy pól

l Nazwy pól są zapisane w całości małymi literami, a poszczególne słowa rozdzielone są podkreśleniami l Nazwy pól są podawane w liczbie pojedynczej, chyba że zawierają treść wskazującą na wiele elementów
l Nazwy pół są poprzedzone prefiksem składającym się z pierwszych liter poszczególnych członów nazwy tabeli, np. dla tabeli kategorie_uzytkownokow - ku_id
l W przypadku nazw pól nie jest zabronione stosowanie nazw zastrzeżonych, gdyż zgodnie z niniejszą zasadą nazwy pól są zawsze poprzedzane prefiksem od nazwy tablicy. W innym przypadku nazwy nie moglyby zawierać nazw zastrzeżonych.

Komentarze

Zazwyczaj, po przygotowaniu skryptu, gdy patrzymy na pięknie napisany kod widząc jego przejrzystość jesteśmy zafascynowani, że nawet nie potrzeba słowa komentarza. Wszystko jest oczywiste. Ale już tydzień później tak oczywistym to nie jest, a po miesiącu... Po trzech to już czara magia.
No cóż każdy przez to przeszedł.

Komentarze powinny opisać jak wszystko działa. W zasadzie nigdy komentarzy zbyt wiele, ale jak pominiesz to, że "obiecałeś zrobić coś z tym plikiem tydzień temu, ale, że zabalowałeś, to dopiero zabrałeś za niego trzy dni później a tak naprawdę to robisz dopiero dzisiaj i strasznie boli Cię głowa, etc... to chyba się nikt nie pogniewa.

Nagłówek
Każdy plik powinien zawierać informacje według poniższego wzoru, gdzie cześć:

l pierwsza - informacje co do używanego edytora i jego ustawień,l wersja oprogramowania, dla której pisany był kod l trzecia nazwę pliku, l czwarta - od projektu podstawowego,
l piąta - opis zadań wykonywanych przez plik (bez przesady oczywiście i nawet może być pominięta, jeśli nazwa pliku wskazuje na zadania wykonywane przez plik), l szósta - opis zmiennych (z wyszczególnieniem tych, które korzystają z wartości domyślnych), l siódma - niezbędnych plików do funkcjonowania, l ósma - zasad korzystania, kopiowania, używania i praw autorskich, l dziewiąta - osób, które pracowały nad plikiem.

Poniżej przedstawiam przykład takiego nagłówka:
codeDivStart() /* nazwa edytora:
 +-------------------------------------------------------------------+
 | PHP version 4                                                     |
 +-------------------------------------------------------------------+
 | index.php                                                         |
 +-------------------------------------------------------------------+
 | Niniejszy plik jest częścią projektu System Obsługi Stron WWW     |
 +-------------------------------------------------------------------+
 | 1. Czynność pierwsza jaka robi niniejszy plik                     |
 | 2. Czynność druga                                                 |
 | 3. Czynność trzecia                                               |
 | 4. Czynność czwarta                                               |
 | 5. Czynność piąta                                                 |
 +-------------------------------------------------------------------+
 | Zmienne:                                                          |
 |    $zmienna1 - ot taki przykład                                   |
 |    $zmienna2 - ot taki przykład                                   |
 |    $zmienna3 - ot taki przykład                                   |
 +-------------------------------------------------------------------+
 |    haselka.php - bardzo wazny plik                                |
 +-------------------------------------------------------------------+
 |          OPROGROMAWANIE MOŻNA STOSOWAC POD WARUNKIEM,             |
 |        ZE UWAZA SIĘ I Z TY ZGADZA DO TEGO CO NASTEPUJE:           |
 | Autorzy nie ponosza odpowiedzialnosci za dzialanie programu. Cala |
 | odpowiedzialnosc spoczywa na osobach konfigurujacych aplikacje    |
 | lub w inny sposob korzystajacy z kodu                             |
 | Prawa autorskie: Grupa programistów pracujących społecznie i bez  |
 | jakichkolwiek pieniedzy w ramach projektow OPEN SOURCE.           |
 | Pozostawiane jest prawo do swobodnego kopiowania, zmieniania kodu |
 | jego upowszechniania na zasadach licencji GNU GPL.                |
 |                                                                   |
 | UWAGA:                                                            |
 |       W przypadku wykorzystania niniejszego oprogramowania lub    |
 | jego czesci należy umiescic niniejsza uwage, ze nikt nie ma prawa |
 | do wlaczania niniejszego kodu w calosci lub tylko jego czesci     |
 | do aplikacji, za które będzie pobieral jakiekolwiek wynagrodzenie |
 | Kod ten powinna być zawsze dostepna dla wszystkich bezplatnie     |
 | Z tego ograniczenia sa zwolnieni wszyscy, którzy sa wskazani jako |
 | autorzy w projekcie wskazanym w naglowku.                         |
+-------------------------------------------------------------------+
 | Autorzy:                                                          |
 |     rooddee <roodee.serwer.com>                                   |
 |     ktos_inny < ktos_inny.polbox.com>                             |
 +-------------------------------------------------------------------+
*/

Za autorów uważa się inicjatorów powstania kodu wraz z osobami, które dokonały przynajmniej od 10% do 20% zmian w kodzie. Prosta reorganizacja kodu i poprawienie błędów nie może być uważana za wystarczającą podstawę do dodania do listy autorów.

Komentarze w kodzie PHP:
codeDivStart() /* Jedna linia komentarza (zajmuje całą linię)  */

codeDivStart() Kod(); // Komentarz w tej samej linii, w której znajduje się linia.

codeDivStart() /*
 * Bardzo ważna jedna linia komentarza
 */
codeDivStart() /*
 * Wielowierszowy komentarz. Tutaj już mogą znaleźć całe
 * zdania. Wyglądem swym przypominają paragraf
 */
Używany w perlu i shelu sposób komentowania przy pomocy # jest nie poprawny! !

Słowa specjalne w komentarzach
W komentarzach stosuje się również słowa specjalne. Mogą one być pomocne w czasie parsowania skryptu.
:TODO: topic
Oznacza, to co jest do zrobienia, po to by o tym nie zapomnieć

:BUG: [ID_bledu] topic
tak wpisujesz zauważone błędy, wyjaśń tu co się dzieje i prawdopodobne przyczyny błędu oraz ewentualnie nadaj ID błędowi

:KLUDGE:
Jeśli nie jesteś zadowolony z wykonanej pracy, to poinformuj o tym i napisz co byś zmienił, gdybyś miał więcej czasu. Ale bez fałszywej skromności

:TRICKY:
Poinformuj, ze ta czesc kodu może kryć niespodzianku, tak, by jeśli ktoś chce zmieniać kod, to najpierw długo o tym myslał.

:WARNING:
Ostrzeż przed czymś

:PARSE:
czasami nie da się nic zrobić z kodem i trzeba obejść problem. Powiadom o tym.

:ATTRIBUTE: value
Możesz tworzyć własne atrybuty o nazwach stworzonych przez siebie.

W przypadku stosowania słów kluczowych w komentarzach wskazane jest by slowo kluczowe było pierwszym slowem komentarza, a nastepnie nazwa zapisujacego komentarz i date wpisu w formacie YYMMDD oraz nazwa problemu. Ponizej należy opisać problem.
Np.
codeDivStart() /*
 * TODO: Sl@o 020907 dokonczyć ten standard kodowania
 * Musze czym szybciej dokończyć ten system kodowania i umieścić
 * go na forum, by inni go skomentowali i nanieśli
 * własne poprawki. Mam nadzieje, ze nie skrzyczą.
*/

Komentarze w wersji podstawowej pisane sa w jezyku polskim. Dla celow szerszego upublicznienia aplikacji wykonywane beda wersje w jezyku o charakterze miedzynarodowym.
Nawiasy i spacje z nimi zwiazane

Nawiasy sześcienne {}

Nawiasy sześcienne {} pozostawiane są samotnie w nowej linii, chyba, ze cale wyrażenie mieści się w jednej linii. Nawias znajduje się w tej samej kolumnie co pierwsza litera wyrazu wywołującego blok. Ten sposób zapisu pewnie nie podoba się tradycjonalistom, ale ma uzasadnienie praktyczne i jest preferowany. Jest poza tym zgodne z zasadami przyjetymi w manualu PHP i wielu aplikacjami Open Source

Nawiasy ()

l Spację należy wstawić pomiędzy słowami kluczowymi (np. if, while, for) oraz nawiasem otwierającym oraz nawiasem zamykającym i nawiasem sześciennym, otwierającym blok, jeśli znajduje się w tej samej linii
l Po nazwie funkcji spacji nie należy wstawiać, podobnie po ( i [ oraz przed ] i ). Spacja rozdzielamy zmienne po przecinku, np.
codeDivStart() function($a, $b); l Po słowie return nie należy wstawiać nawiasów, jeśli to nie jest konieczne.

Np. codeDivStart() function jakastam()                           // Komentarz
{
    if ($warunek) {mieści się w jednej linii}
    elseif ($warunek)                     // Komentarz
    {
        długi lub wieloliniowy tekst
    }
    elseif ($warunek)                      // Komentarz
    {
        if ($warunek2)
        {
            while ($warunek3)              // Komentarz
            {
                długi lub wieloliniowy tekst
            }
        }
    }
}

strcmp($s1, $s2);

return 1;
Istotne warunki co do kodowania PHP

l Zawsze używać pary znaczników <?php ?>, a nie <? ?>, co zapewnia większe prawdopodobieństwo poprawnego wykonywania skryptu przez jednoznaczność znacznika i większą kompatybilność z już istniejącymi systemami.
l Wszystkie pliki PHP powinny być plikami wykonywalnymi. Oznacza to, że wszystkie pliki powinny mieć standardowo określone rozszerzenie .php. Jednakże w trakcie pisania kodu nazwy plików będą określane jako złożenie nazwy właściwej i zmiennej i rozszerzenia, np. nazwa . $php, gdzie $php=".php";
l Wiersze (linie) tekstu kończone będą za pomocą "\n" zamiast innych rozwiązań alternatywnych
l Raczej stosuj require niż include (właściwie dlaczego? )
l Podłączając plik klasy stosować w przypadku podłączania bezwarunkowego require_once(), w przypadku warunkowego include_once(). Zawsze jednak zwracaj uwagę, by klasa była podpięta tylko raz, chociaż stosują one tą sama listę plików i raczej nie powinna istnieć obawa, że po zastosowaniu require_once() nastąpi podłączenie tych samych plików za pomocą funkcji include_once(). Polecenia require_once() oraz include_once() nie potrzebują cudzysłowów.
l Funkcji phpinfo nigdy nie wolno umieszczać w treści kodu, z uwagi na brak możliwości zabezpieczenia za pomocą hasła.

Wskazania i preferencje co do kodowania PHP

l Zmienna $GLOBAL nigdy nie może być użyta w funkcjach lub klasach funkcji, z wyjątkiem wartości konfiguracyjnych
l Dane konfiguracyjne powinny być włączone ze specjalnych plików konfiguracyjnych i powinny w jak najmniejszym stopniu zawierać tablice z opcjami zależnymi l Do funkcji powinno być dodanych kilka linii komentarza opisującego opis funkcji, definicje i wyjaśnienia co do argumentów, prawdopodobne typy wyników i ich wartości oraz wyjaśnienia ich znaczeń, a również przykłady zastosowań funkcji l Należy używać raczej komendy print niż echo
lUnikaj częstych przełączeń pomiędzy PHP i HTML w przypadku ich bliskości.

Obsługa błędów

l Sprawdzaj system, czy nie ma błędów, chyba, że chcesz znane błędy ignorować.
l Wprowadź informację z nazwami błędów do każdej informacji o błędach.

Kodowanie PHP na styku z SQL i tablicami

Kod należy pisać tak, by łatwo było go modyfikować, a szczególnie odpluskwiać. Wyniki zapytań zawsze musza być sprawdzane pod względem zwracanych wyników i zgłaszanych wyników.

l Słowa kluczowe SQL powinny być pisane w całości wielkimi literami. Nazwy tablic oraz pól, jeśli to możliwe, zaleca pisać się małymi literami. W przypadku zapytań o długości przekraczających jedną linię zapytanie dzielimy w przed lub po słowie kluczowym SQL

codeDivStart() $zap = "SELECT u_uzytkownik AS uzytkownik, u_imie AS imie,
              u_nazwisko AS nazwisko
       FROM uzytkownik, grupy_uzytkownikow, grupy
       WHERE
         u_id = ugm_u_id
           AND
         ugm_g_id = g_id
           AND
         g_name ='$okreslona_grupa'
       ORDER BY uzytkownik ASC";

l W przypadku błędów nigdy nie powinna wyświetlać się treść zapytania ($query), chyba, że celowo zostało to tak ustawione. Wyświetlenie zmiennej $query mogą pozwolić użytkownikowi na poznanie struktury danych, a przez to ułatwić uszkodzenie bazy danych, a może i całej aplikacji.
l W przypadku słów kluczowych i wartości umieszczanych w array, powinny one być ujęte w cudzysłów.
codeDivStart() $tmp =$array[key];  //źle
$tmp =$array["key"];  //dobrzel Unikaj umieszczania tablic w środku cudzysłowów dla kodu PHP

codeDivStart() $str = "To jest niewłaściwy sposób wstawiania $array[w_ten_sposób]";
$str = "To jest właściwy sposób wstawiania" . $array ["w_ten_sposób"];
Kodowanie baz danych

l Używać należy pól text dla pól, które mają charakter znakowy, a nie są bezpośrednio powiązane z innymi typami danych, chyba że zawsze ich długość jest ograniczona (wtedy lepiej użyć varchar lub char.
l W przypadku pól służących do wpisywania daty lub czasu należy zawsze stosować datatime nawet jeśli zależy nam na części data lub time.
l Dla pól mających na celu podanie wartości logicznych co prawdy i fałszu będą zawsze używane pola o charakterze logicznym, bool i boolen są tego dobrym przykładem.
l Poza wyjątkowymi sytuacjami, pola powinny mieć ustaloną wartość not null. Takie pola powinny mieć określoną wartość domyślną (default)

Kodowanie HTML

Kodowanie HTML opiera się na rekomendacji Konsorcjum W3 co do XHTML
Nizej podane sa niektore zmiany w stosunku do tego co wiekszosc zna z czystego html. Stsowanie pelnego formatowania z XHTML mile widziane i zalecane.

l Nie ma tu ograniczenia co do długości linii do 80 znaków. Oczywiście krótsze linie są mile widziane. l Kolejne poziomy zagnieżdżenia powinny być wyróżnione za pomocą dodatkowej spacji, np. codeDivStart() <table>
 <tbody>
  <tr>
<td>Jakiś tekst</td>
  </tr>
  <tr>
   <td>
    No i znowu tekst
   </td>
  </tr>
 </tbody>
</table>
l Elementu, znaczniki i atrybuty powinny być pisane z malej liter.
l Wszystkie poziomy zagnieżdżenia powinny być zamknięte za pomocą znaczników zamykających, a w przypadku znaczników zamykających zbiory puste za pomocą znaczników specjalnych (nie dotyczy to znacznika komentarza. codeDivStart() <p>paragraf         <!-- niepoprawnie -->
<p>paragraf</p>     <!-- poprawnie -->
<br>                <!-- niepoprawnie -->
<br />              <!-- poprawnie -->
l Poszczególne poziomy powinny być poprawnie zagnieżdżone codeDivStart() <p>To jet <b>paragraf</p></b>           <!-- niepoprawnie -->
<p>To jet <b>paragraf</b></p>     <!-- poprawnie -->
l Atrybuty zawsze musza być zamknięte w cudzysłowach, nawet liczby codeDivStart() <input type="text" name="uzytkownicy" size="8">
l Wszystkie atrybuty muszą mieć podane wartości. Jeżeli w przypadku HTML stosowania wartości dla atrybutu nie przewidziano to wartość atrybutu jest taka sama jak nazwa atrybutu. codeDivStart() <input type="checkbox" name="enabled" value="t" checked>   <!-- niepoprawnie -->
<input type="checkbox" name="enabled" value="t" checked="checked"> <!-- poprawnie -->
l Komentarz w stylu HTML można robić tylko wówczas, gdy w zamiarze ma być on widoczny dla użytkowników. W każdym innym przypadku komentarze należy wstawiać jako komentarze PHP.
l Należy sprawdzać, by całość była wyświetlana tak by była możliwa do zaakceptowania nawet, gdy nie ma dostępu do CSS lub JavaScript jest wyłączony
l Należy zwracać uwagę na ortografię
l Strony muszą być poprawnie wyświetlane i funkcjonalne pod następującymi przeglądarkami: MsIE5 i 6, Netscape6 i 7, Gozzilla, Mozzilla, Galeon działającymi pod Windowsami i Linuxem (jeśli maja wersję linuxową)

zanotowane.pl

doc.pisz.pl

pdf.pisz.pl

wyciskamy.pev.pl

Linki

• Pary_anime
• : 08. Kodowanie PHP na styku z SQL i tablicami
• : 07. Istotne warunki co do kodowania PHP
• : 09. Kodowanie baz danych
• : 10. Kodowanie HTML
• : Założenia co do kodowania
• : 01. Po co jakiś standard?
• Standardowo Witam :)
• witam serdecznie
• : Zamarzanie wody w rurach - nie zlekcewaĹźcie problemu!
• Przygody Merlina - Sezon 2
• zanotowane.pl
• doc.pisz.pl
• pdf.pisz.pl
• sylwina.xlx.pl

Cytat

Dobre kobiety są lepsze niż dobrzy mężczyźni. Złe kobiety są gorsze niż źli mężczyźni. Marcel Achard
Dobry komplement to nie ten, który słodki, lecz ten, który prawdziwy. Lewandowska Ewa
Aby kraj mógł żyć, trzeba, aby żyły prawa. Adam Mickiewicz
Ograniczony umysł wyżywa się w nieograniczonych ambicjach. Jerzy Drobnik
Gdyby wynik wojny można było przewidzieć, żadnych by nie było. Hermann Bondi