Ako riesite prehladnost svojho kodu?

Monkeys:
„1) Davate utrzky kodu do externeho suboru?“
je-li potreba a vyzaduje-li to adresarova, resp. souborova struktura, vice souboru se bezne pouziva. Nebo jsi snad videl nejaky projekt (nebavime se o webu o 10 strankach), ktery by byl v jednom kilometrovem souboru?

„2) Pouzivate mnozstvo funkcii?“
asi tolik, kolik jich je potreba

„3) Co v pripade ked sa kod vetvi povedzme aj na 3,4 if, else if ?“
switch znas?

Na tyto otazky nelze se vseobecnou platnosti odpovedet jinak, nez obecne. Pocet pouzitych souboru i pocet funkci se lisi per project.

Monkeys:
„ked sa na nieco pozrem po niekolkych mesiacoch neviem kam skor pozerat“
A když na ten kód s odstupem času koukáte, proč se vám špatně čte? Musíte skákat sem a tam mezi voláním a definicí funkce, abyste si připomněl, co vlastně ta funkce dělá / vrací? Nemohla by být pojmenovaná lépe, výstižněji? Dělá funkce opravdu jen jednu věc (= měla by), anebo nějakým parametrem přepínáte její chování? Používáte jednotný styl kódu (odsazení, způsob zápisu názvů proměnných/fcí/tříd/...)? Neopakují se vám v (třeba i v různých souborech) bloky kódu, které by šlo vytknout do funkce? Jsou všechny funkce/metody zapouzdřené, anebo si potají samy odněkud čtou/zapisují data (global, $_GET/POST)? Máte oddělené vrstvy prezentace (šablony), logiky a přistupu k datům?

Zkuste číst cizí kód, klidně i v jiném jazyku, a vnímejte jestli rozumíte tomu, co to dělá nebo ne. Nemusíte vidět implementaci metody - pokud je dobře pojmenovaná, mělo by být zřejmé co přesně dělá (např. když se něco jmenuje otázkou - isOnline, hasPermission, očekávám, že to vrací logickou hodnotu). Nebo si prolistujte pár knížek o vývoji SW - i když hodně z toho třeba zatím nevyužijete, aspoň vás to postrčí správným směrem.

A ešte by som doplnil použitie komentárov.
Keď mi je pri písaní jasné, že o pol roka na to budem čumieť ako puk, tak tam dám komentár.

A napríklad pri tých if-och používam syntax:

Najmä v zmiešanom kóde php + html je to podstatne výrečnejšie, než jedna zložená zátvorka ;-)

Giga:
k tomuto tvemu zapisu: moc prakticky neni, uz jen proto, ze si nevzpominam na editor, ktery by ti dokazal nejak obarvit souvisejici if a endif. U zavorek to umi vsechny normalni.

„Najmä v zmiešanom kóde php + html“
to je druha vec. Obe tyto vrstvy by mely byt od sebe oddelene.

Monkeys:
Předpokládám, že s programováním spíš začínáš, takže pár obecných rad:

1) Dávej si hodně záležet na pojmenování. Už z názvu proměnné by mělo být patrné, co asi obsahuje, z názvu funkcí by mělo být patrné, co asi bude dělat, z názvů parametrů funkcí by mělo být patrné, co očekávají, že do nich předáš.
2) Striktně dodržuj coding standard (jednotné odsazování, umístění závorek, psaní mezer okolo operátorů…). Je docela jedno, jaký coding standard si vybereš, ale hlavně ho dodržuj důsledně.
3) Kód rozumně čleň do více souborů a funkcí. Délka většiny funkcí by neměla přesáhnout 20 řádků.
4) Minimalizuj globální závislosti. Chování funkcí by ideálně nemělo záviset na žádných globálních proměnných.
5) Piš rozumné množství komentářů. Každá funkce by měla mít phpDoc komentář, který popisuje, co funkce dělá, jaké parametry očekává a co vrací.

Monkeys:
na toto se pouzivaji sablonovaci systemy. O nich si neco precti, pokud mas zajem.

Pokud mas staticky web o peti strankach, muze to byt relativne prehledne, i kdyz bude vse v jednom souboru. U vetsiho projektu se bez sablonovani neobejdes. Nejake teoreticke info + priklady impementace (napr. Nette) je treba na wikipedii.

Monkeys:
spravne to neni (z hlediska udrzby, zejmena vetsich projektu), ael pokud ti to takhle vyhovuje, proc ne.

Monkeys:
„Robim to takto spravne ?“
To je relativní. Jde to dělat výrazně hůře, ale jde to i výrazně lépe. Předpokládám tedy, že tě zajímá, jak to dělat „o jeden stupeň lépe“.

Nejprve drobnosti:
1) mysql_close není potřeba volat, spojení se bezpečně uzavře samo.
2) require a include nejsou funkce, ale jazykové konstrukce, takže je zvykem vynechávat závorky (stejně, jako třeba u echo).
3) Soubor conect.php by se pravděpodobně měl jmenovat connect.php.
4) Je dobrým zvykem psát všechny cesty pokud možno absolutně, např.

Teď k té samotné architektuře:
Jak už psal panther, míchání HTML a PHP/SQL se nejlépe zbavíš použitím šablonovacího systému. Dobrý šablonovací systém je např. Latte nebo Twig.

Vlastní stránka by pak měla vypadat např. takto:

Monkeys:
„Este sa chcem opyta aky je rozdiel medzi objektovym programovanim a (neviem ako to nazvat) normalnym ?“
Zjednodušeně: Objektové programování je o jiném způsobu myšlení. Objekty ti umožní mnohem lépe „namodelovat“ a „rozebrat“ složitější problémy, proto drtivá většina větších moderních aplikací se dnes píše objektově.

Monkeys:
Není to o syntaxi, je to úplně o jiném přístupu k návrhu aplikace, viz Jan Tvrdík
BTW co jsem si ale přečetl o Tvém návrhu + rady, bude to už IMHO dostatečně přehledné.
Ještě bych dodal za sebe, že nasazení šablonovacího systému a oddělení HTML a PHP kódu bylo největší zpřehlednění mého CMS. Šablony klidně mohou být v samotným PHP, já používám Smarty.
panther:
Bohužel jsem už viděl menší CMS napsané skoro v jednom souboru (byly tam všechny akce z admin části). Ten soubor měl cca 5500 řádků a 250kB...

panther:
viděl jsem (a měl jsem tu "čest" :D spravovat) eshop napsaný víceméně ve 2 souborech, zbastleno html, sql a php dokupy ... jeden soubor asi 4.5k řádků, druhej asi 9k, to je pak bomba, zvláště když tam nejsou ani dobře odsazení.