Po co jakiś standard?

Po co jakiś standard?
Styl pracy nad projektem
Przygotowanie projektu
Tworzenie nazw
Komentarze
Nawiasy i spacje
Układ strony
Kodowanie HTML
Istotne warunki co do kodowania PHP
Kodowanie baz danych

A życie mogło być tak proste...

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

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. 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ć :-)).

Dlaczego nie warto stosować standaryzacji w oprogramowaniu Open Source?

Standaryzacja to straszna przeszkoda i same kłopoty.

• 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ł.

• każda standaryzacja jest głupia 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ę.

• standardy krępują 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ę!

• 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óźniej

• Nie ma nic fajniejszego jak robienie tych samych błędów na nowo i na nowo bez końca.

• po co stosować standardy. Przecież wszyscy są tacy sami i myślą tak samo.

• I tak nikt nie stosuje się do standardów

A teraz już serio :-)))))

Styl pracy nad projektem

• Podstawowym celem jest stworzenie aplikacji działającej poprawnie, a dopiero w dalszej kolejności dołączenie cech nadzwyczajnych i innych bajerów.

• 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 aplikacji.

• Wszystkie komponenty powinny być tak projektowane, by pozwalać na ich prosta administrację, czy konfigurację.

• Większa dbałość o czytelność kody PHP niż kodu HTML.

• Dbałość o jak najprostsze i banalne rozwiązania. Czym prostsze i głupsze tym lepsze.

Z uwagi na tworzenie systemu Open Source:

• wszystkie nazwy zmiennych, funkcji, metod, tablic, pól, klas. etc powinny być pisane w języku o charakterze międzynarodowym (wskazany: angielski).

• komentarze i nagłówki w wersji udostępniane jako kolejne wersje aplikacji powinny być podane w języku o charakterze międzynarodowym (wskazany: angielski) - w przypadku wersji lokalnych mogą być podane w lokalnej wersji językowej.

Przygotowanie projektu

• weź dużą kartkę papieru i ołówek - czasem dobrze jest poświęcić kilka dni na rozrysowanie programu na papierze niż tygodnie na szukanie błędów

• jak już sobie wszystko poukładasz, wyodrębnij moduły/funkcje, zastanów się czy istnieją standardowe biblioteki które możesz zaprząc do pracy

• gdy już zaczynasz kodowanie trzymaj się jakiejś konwencji (kodowania) i bądź w tym konsekwentny, nie zapominaj o dokumentowaniu kodu

• darz skrajną nieufnością wszystko co mówi zleceniodawca i licz się z tym, że cokolwiek napiszesz może następnego dnia okazać się niepotrzebne/złe/działające nie tak jak sobie życzy klient

• stwórz/wykorzystaj mechanizmy umożliwiające debugging podczas testowania aplikacji oraz wyszukiwania błędów, podczas sporadycznych padów całego systemu

• zaprojektuj dobrze bazę i relacje i staraj się nie zmieniać ich w trakcie pisania

• przyjmij odpowiednie nazewnictwo zmiennych i funkcji, pisz obiektowo, komentuj kod, pisz modułowo, rób dobre configi i skrypty instalacyjne, zapewnij (o ile to możliwe) raportowanie o błędach i próbach włamań, trzymaj plik z hasłami powyżej drzewa dostępnego przez WWW (o ile możesz), stosuj odpowiednią tabulację.

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śleniem, człony nazwy pakietu powinny być pisane wszystkim dużymi literami.

 Np.
  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.
  Logowanie, Logowanie_Uzytkownika, Wprowadzenie_Nowego_Szablonu

W przypadku korzystania z biblioteki klas, jako prefiksu należy użyć nazwy pakietu.

 Np.
  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.
  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 coś jest.
• Get - w celu pobrania wartości
• Set - w celu ustalenia wartości.

 Np.
  IsOdpowiedz - Czy jest odpowiedź?

Ż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

W przypadku funkcji w tzw. klasach prywatnych zaleca się je poprzedzać pojedynczym podkreśleniem.

 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.

 Kod:
  $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ślenia, nazwy pakietu oraz kolejnego podkreślenia.

 Kod:
  $_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

• Nazwy tablic są zapisane w całości małymi literami, a poszczególne słowa rozdzielone są podkreśleniami.

• Nazwy tablic są podawane w liczbie mnogiej zgodnie z tym co zawierają, tj. zawsze należy pisać uzytkownicy zamiast uzytkownik.

• Nazwy pól są zapisane w całości małymi literami, a poszczególne słowa rozdzielone są podkreśleniami.

• Nazwy pól są podawane w liczbie pojedynczej, chyba że zawierają treść wskazującą na wiele elementów.

• Nazwy pól są poprzedzone prefiksem składającym się z pierwszych liter poszczególnych członów nazwy tabeli, np. dla tabeli kategorie_uzytkownikow - ku_id.

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

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

  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

W przypadku nazw pól to nie jest istotny warunek, gdyż nazwy pól są zawsze poprzedzane prefiksem od nazwy tablicy.

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ść:

• pierwsza - informacje co do używanego edytora i jego ustawień,
• wersja oprogramowania, dla której pisany był kod
• trzecia nazwę pliku,
• czwarta - od projektu podstawowego,
• 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),
• szósta - opis zmiennych (z wyszczególnieniem tych, które korzystają z wartości domyślnych),
• siódma - niezbędnych plików do funkcjonowania,
• ósma - zasad korzystania, kopiowania, używania i praw autorskich,
• dziewiąta - osób, które pracowały nad plikiem.

Poniżej przedstawiam przykład takiego nagłówka:

 Kod:
/* 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:

 Kod:

  /* Jedna linia komentarza (zajmuje całą linię)  */

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

  /*
    Bardzo ważna jedna linia komentarza
  */

  /*
    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śniasz co się tutaj dzieje oraz podajesz prawdopodobne przyczyny błędu - ewentualnie nadaj błędowi ID

 :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, że ta część kodu może kryć niespodzianki, tak, by jeśli ktoś chce zmieniać kod, najpierw dobrze to przemyślał.

 :WARNING:
  Ostrzeżenie 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 słowo kluczowe było pierwszym słowem komentarza, a następnie nazwa zapisującego komentarz i data wpisu w formacie YYMMDD oraz nazwa problemu. Poniżej należy opisać problem.

 Np.:
 /*
  * TODO: Sl@o 020907 dokończyć 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ą.
 */

Nawiasy i spacje

Nawiasy klamrowe {}

• Nawiasy klamrowe {} pozostawiane są samotnie w nowej linii, chyba, że całe 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.

Nawiasy ()

• 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.

• Po nazwie funkcji spacji nie należy wstawiać, podobnie po ( i [ oraz przed ] i ). Spacja rozdzielamy zmienne po przecinku, np.:

   Kod:
    function($a, $b);
  

• Po słowie return nie należy wstawiać nawiasów, jeśli to nie jest konieczne.

   Kod:
    function jakastam()                           // Komentarz
    {
       if ($warunek) {mieści się w jednej linii}
       elseif ($warunek)				// Komentarz
       {
          długi lub wieloliniowy tekst
       }
       else					// Komentarz
       {
          if ($warunek2)
          {
              while ($warunek3)			// Komentarz
              {
                  długi lub wieloliniowy tekst
              }
          }
       }
    }
  
    strcmp($s1, $s2);
  
    return 1;
  

Układ strony

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

1. Szerokość strony
   • Kod PHP (z wyjątkiem wstawek do HTML) musi mieścić się linii 80-o znakowej.

   • Powyższa zasada nie jest stosowana w przypadku kodu HTML, ale oczywiście przestrzeganie tej zasady jest mile widziane.

2. Wcięcia:
   • Standardowo należy używać wcięcia o długości 4 spacji w przypadku kodu PHP i jedna 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ść.

3. 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.

 Kod:
  $rezultat = stworz_uzytkownika ($uzytkownik, $haslo, $nazwisko
				  $telefon, $email)

Kodowanie HTML

Kodowanie HTML opiera się na rekomendacji Konsorcjum W3 co do XHTML.

• Nie ma tu ograniczenia co do długości linii do 80 znaków. Oczywiście krótsze linie są mile widziane.

• Kolejne poziomy zagnieżdżenia powinny być wyróżnione za pomocą dodatkowej spacji, np.:

   Kod:
    <table>
    <tbody>
     <tr>
      <td>Jakiś tekst</td>
     </tr>
     <tr>
      <td>
       No i znowu tekst
      </td>
     </tr>
    </tbody>
    </table>
  

• Elementy, znaczniki i atrybuty powinny być pisane małymi literami.

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

   Kod:
    <p>paragraf			<!-- niepoprawnie -->
    <p>paragraf</p>		<!-- poprawnie -->
    <br>				<!-- niepoprawnie -->
    <br />			<!-- poprawnie -->
    <br></br>			<!-- poprawnie -->
  

• Poszczególne poziomy powinny być poprawnie zagnieżdżone:

   Kod:
    <p>To jest <b>paragraf</p></b>	<!-- niepoprawnie -->
    <p>To jest <b>paragraf</b></p>	<!-- poprawnie -->
  

• Atrybuty zawsze muszą być zamknięte w cudzysłowach, nawet liczby:

   Kod:
    <input type="text" name="uzytkownicy" size="8">
  

• 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:

   Kod:
    <input type="checkbox" name="enabled" value="t" checked>		<!-- niepoprawnie -->
    <input type="checkbox" name="enabled" value="t" checked="checked">	<!-- poprawnie -->
  

• 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.

• 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.

• Należy zwracać uwagę na ortografię.

• 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ą).

Istotne warunki co do kodowania PHP

• 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.

• 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";

• Wiersze (linie) tekstu kończone będą za pomocą "\n" zamiast innych rozwiązań alternatywnych.

• Raczej stosuj require niż include (właściwie dlaczego???)

• 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.

• 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

• Zmienna $GLOBAL nigdy nie może być użyta w funkcjach lub klasach funkcji, z wyjątkiem wartości konfiguracyjnych.

• Dane konfiguracyjne powinny być włączone ze specjalnych plików konfiguracyjnych i powinny w jak najmniejszym stopniu zawierać tablice z opcjami zależnymi.

• 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.

• Należy używać raczej komendy print niż echo.

• Unikaj częstych przełączeń pomiędzy PHP i HTML w przypadku ich bliskości.

Obsługa błędów

• ustaw obsługę błędów na E_ALL. Po zakończeniu testowania możesz ją wyłączysz:

   error_reporting(E_ALL);
  

• Sprawdzaj system, czy nie ma błędów, chyba, że chcesz znane błędy ignorować.

• Wprowadź informację z nazwami błędów do każdej informacji o błędach.

Kodowanie baz danych

• 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).

• 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.

• Bool i boolen będą zawsze używane dla pól mających na celu podanie wartości logicznych co prawdy i fałszu.

• Poza wyjątkowymi sytuacjami, pola powinny mieć ustaloną wartość not null. Takie pola powinny mieć określoną wartość domyślną (default).

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.

• 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:

   Kod:
    $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";
  

• 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.

• Błędy należy wyświetlać po każdym poleceniu SQL.

   $result = "SELECT * FROM nazwa_tabeli WHERE cos ORDER BY tytul";
   if (!result) {"BŁĄD: " . mysql_error();}
  

• W przypadku słów kluczowych i wartości umieszczanych w array, powinny one być ujęte w cudzysłów:

   Kod:
    $tmp =$array[key];		//źle
    $tmp =$array["key"];		//dobrze
  

• Unikaj umieszczania tablic w środku cudzysłowów dla kodu PHP.

   Cytat:
    $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"];
  

[ POCZĄTEK ] |  [ MENU ] |  [ KONIEC ]

Jeżeli spodobały ci się nasze strony możesz je Dodać do Ulubionych lub ustawić tą stronę jako swoją Stronę główną. Możesz też wysłać swojemu znajomemu lub znajomej LINK do naszej strony.

Strona główna     Dodaj do ulubionych     Ustaw jako stronę główną     Wyślij link znajomemu/znajomej

Z TEJ STRONY SKORZYSTAŁO JUŻ: OSÓB

---

Copyright © 1997-2005 MS STUDIO - Wszelkie prawa zastrzeżone
Opracowanie i administracja MS STUDIO | O NAS
Uwagi techniczne: Slawi | Security HeniO