PHP styl

Docela dobré tipy najdeš tu: http://www.majda.cz/vyuka/2006-2007/swi113/slajdy.html

Co by změnil:
* konzistentní odsazení - preferuji 4 nebo 8 znaků a poctivě odsazovat (!). Bez odsazení je to krajně nečitelné
pokud bys měl problém, že tam máš moc zanořených ifu, lze to třeba zabalit do funkce nebo vyřešit jako první případy, kdy to selže, viz

nahradit

* omezil bych počet znaků na řádek. Mám 22' monitor a stejně se mi to tam nevejde
* na jeden řádek jeden příkaz. Platí i pro break;
* ten první switch bych dal do funkce. Místo switch bych použil pole, poté bych dosadil pomocí $link = $pole[$_SERVER['HTTP_HOST'];
* obecně používat funkce
* místo addslashes používat mysql_real_escape pro dotazy do databáze
* ke každému mysql_query doplnit or die(mysql_error()); Ještě lépe si udělat funkci, která dostane na vstupu dotaz, vrátí výsledek, pokud proběhla úspěšně, jinak vypíše dotaz i chybu. A pokud to bude na produkčním serveru, tak zobrazí uživateli chybovou hlášku.
* $_SESSION['verificationCodeImage'] = $verificationCodeImage; -- tenhle řádek je tam 5x. Chtělo by to upravit tak, aby tam byl jen jednou
* za header zavolat exit;
* nechám prostor i dalším :)

„Někde jsem četl, že If je lepší nahradit switchem“
Ale pouze ve specifickém případě. Switch se hodí, když kontroluješ jeden výraz/proměnnou a podle jeho hodnoty se můžeš dostat do více (alespoň 3) různých větví. Pokud jsou jen 2 větve, měl by to obstarat klasický if{}else{}, a pokud máš víc větví ale pomocí switche to zapsat nejde (má dost omezené možnosti, jednu hodnotu kontroluješ na rovnost s N dalšími), není nic špatného na tom použít párkrát elseif. Ale když to jde, tak switch, dělá to přinejmenším kód přehlednější.

„V PHP už se učím asi rok, ale stále cítím, že to není ono“
Já si ani po pěti letech nepřijdu že bych snědl všechnu PHP moudrost :) učení se programování je běh na dlouhou trať no...

jinak tam žádné závažné pochybení nevidím, jen to co již zmínil TomášK (především to odsazení je základ přehledného kódu).

Některé tyto rady ber jako věc názoru. Já bych se např. doporučovanému exit a die vyhnul obloukem jako čert kříži.
Sám bych to asi napsal trochu jinak, především bych se snažil více oddělit aplikační logiku a výpis html.
A co mi padlo do oka:

Připojení prázdného řetězce nemá smysl.

Doporučil bych právě takový velký úsek s téměř pouze jen html kódem, který máš v tom echu, dát jako=>když už nic, tak to aspoň bude mít v editoru hezky zvýrazněnou syntaxi

„Já bych se např. doporučovanému exit a die vyhnul obloukem jako čert kříži.“
Mohl by si prosím napsat z jakého důvodu? Nemyslím to vůbec špatně, jen abychom věděli

Nox:
„Mohl by si prosím napsat z jakého důvodu?“
Připadá mi to jako neřízená střela a připomíná mí to "Kdo se neboji goto, nebojí se ničeho."

Asi už myslím moc objektově a pro velké systémy, ale představa násilného ukončení scriptu někde uprostřed mně nepřipadá moc lákavá. Zanořené podmínky bez problému vyřeší dobře napsaná třída (hodit exit na konec každé z deseti zanořených podmínek a po půl roce něco dopisovat na konec, no potěš) a chyby dotazů lze vyřešit také lépe. (viz ukázka dále) Navíc ve většině případů to zůstane stejné na ostrém serveru jako při vývoji (Kdo bude přepisovat všechny die?) Kolik jen už jsem viděl bílých stránek s černým anglickým nápisem, nebo ještě lépe s českým (samozřejmě že s otázníky místo diakritiky, protože nemáme html hlavičku s kódováním) s nápisem informujícím, že selhal jakýsi dotaz (v tom lepším případě). A přitom mohl být vykreslen obvyklý layout stránek se srozumitelnou omluvou a třeba odkazm na kontaktní formulář na admina, nebo ještě lépe přimo logování chyby, což die nedělá.
S tou druhou částí rady "Ještě lépe si udělat funkci, která dostane na vstupu dotaz, vrátí výsledek, pokud proběhla úspěšně, jinak vypíše dotaz i chybu." již zcela souhlasím.

Ukázka z Dibi:



Tohle asi filoo nenapíše, ale považuji to za ideální způsob zachycení chyb.

Alphard
* určitě souhlasím s tím, že je to hodně subjektivní, i proto jsem na začátek psal 'co bych změnil'.
* nebojím se goto :) lze samozřejmě zneužít, ale jsou i místa, kde je kód s goto přehlednější (vyskakování ze zanořených cyklů, dealokace zdrojů) (opět subjektivní).
* exit za header(Location) (u jiných hlaviček to smysl nedávám, uznávám) jsem převzal z dokumentace php - jako pojistku proti vykonání zbývajícího kódu, což většinou není žádoucí, die by opět šel nahradit nějakou obalovací funkcí - která by třeba zalogovala, co se stalo.
* exit v zanořených podmínkách ne. exit na začátku pro ošetření třeba chybných vstupů už se mi zdá rozumný. Pokud to bude ve funkci, tak tam nebude exit, ale return, ale myšlenka zůstává stejná.

Já jsem se spíš snažil vyjít z uvedeného kódu a postupně ho upravovat. Alphard upozornil na to, že už ten návrh jde udělat lépe. S tím souhlasím - pomocí objektů, výjimek je to elegantnější.

Můj vývoj začal procedurálním php - podobným kódem, jako píše filoo. Poté jsem přešel na objektové php - to za moc nestálo, protože jsem s objekty začínal. Napsal jsem si třídu pro databázi, třídu pro každou tabulku v databázi, třídu pro stránku... pak mě napadlo, že tohle řeší každý, hledal jsem, jak to dělají jinde a objevil frameworky. Tam má éra php končí, python nebo ruby se mi líbily víc než php a protože jsem nebyl omezen hostingem, přesedlal jsem na Ruby on Rails. A kam dál? Možná na Javu nebo ASP (o tom moc nevím).
A proč to vlastně píšu? Aby filoo zvážil, jestli se nechce kouknou po nějakém frameworku, mohlo by mu to ušetřit jednu vývojovou fázi :)

P.S. Kdyby někdo dokázal odhadnout můj další vývoj - prošel podobnou cestou a došel dál než já, budu jen rád. Stále objevuju a zatím nevím, kde zakotvím - i k Ruby už mám určité výhrady.

TomášK:
„exit za header(Location) (u jiných hlaviček to smysl nedávám, uznávám) jsem převzal z dokumentace php - jako pojistku proti vykonání zbývajícího kódu, což většinou není žádoucí, die by opět šel nahradit nějakou obalovací funkcí - která by třeba zalogovala, co se stalo.“
S exit za header s přesměrováním souhlasím, nejen kvůli manuálu, ale tak jsi to nenapsal :-)

„exit v zanořených podmínkách ne. exit na začátku pro ošetření třeba chybných vstupů už se mi zdá rozumný. Pokud to bude ve funkci, tak tam nebude exit, ale return, ale myšlenka zůstává stejná.“
Pochopil jsem to tak, že v zanořených podmínkách ano. Ošetření chybných stavů možná, mně se to nelíbí, ale už bych to přijal.

filoo
Neexistuje žádný "obecně" nejlepší framework. Každý má trochu jinou filosofii, jiný stupeň závislosti součástí. Čím víc toho umí, tím déle se ho učíš. Ideální je napsat si vlastní knihovny.

filoo
Vždy záleží na tom, co chceš vytvářet. Liší se nejenom frameworky, ale i databáze. Nejdříve se pořádně rozhlédni.

Mastodont:
„Ideální je napsat si vlastní knihovny.“
To radíš člověku, který právě zjistil, že existují frameworky?

filoo:
Tabulkové přehledy nejsou vždy nejlepším měřítkem. Podstatné je, jak se dá s daným frameworkem pracovat.
Skutečně nejde doporučit jeden nejlepší, je potřeba se porozhlédnout a získat s nimi nějaké zkušenosti.

Chybnou volbou určitě nebude třeba Zend, nebo i Nette. Zend je rozsáhlejší (a pomalejší), Nette neobsahuje zas tolik funkcí, ale i přesto je docela šikovné.
PS: Je mi jasné, že zvláště s tímto odstavcem bude hodně lidí nesouhlasit.

4/8 pro odsazení je moc IMO. Pokud si někdy psal obsáhlejší zdroják, tak s tímhle odsazením se nascrolluješ... Praxe mě naučila, že odsazení 2 je ideální kompromis, samozřejmě nezapomenout nastavit si zaměňování tabulátorů za mezery.

Alphard
Ano, radím. Nikde nepíšu, ať se do jejich psaní pustí hned, ideál je dlouhodobý cíl :)

lordfrikk
Prevence proti scrollování tam je - kombinace velkého odsazení a omezeného počtu znaků na řádek tě donutí psát kód tak, abys neměl víc než tři max čtyři zanoření. Pokud jich máš víc, pak stojí zauvažovat nad tím, jestli ten kód nestojí za to přepsat. Tyhle teorie nemám ze své hlavy, extrém 8 znaků a 80 znaků na řádek doporučuje Linus Torvalds ( http://www.kernel.org/doc/Documentation/CodingStyle ), 4 znaky tuším GNU coding style (obojí pro C, ale zdá se mi, že tohle je přenositelné i do PHP) - aneb používají se i na větších projektech.
Určitě nechci říct, že je to jediné správné řešení a 2 mezery jsou špatné. Jen že je to použitelné a i používané - každý ať si vybere, jen si myslím, že by to mělo být konzistentní v rámci jednoho projektu. O tom, co je nejlepší (stejně tak taby vs mezery,) už bylo napsáno mnoho řádků a jediný smysluplný závěr je imho ten, že to je subjektivní.