Autor Zpráva
Monkeys
Profil *
Ako riesite prehladnost kodu pri vacsich projektoch ?

1) Davate utrzky kodu do externeho suboru?
2) Pouzivate mnozstvo funkcii?
3) Co v pripade ked sa kod vetvi povedzme aj na 3,4 if, else if ?

Dost ma to zaujima lebo ked sa na nieco pozrem po niekolkych mesiacoch neviem kam skor pozerat :)

M.
panther
Profil
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.
Tori
Profil
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.
Giga
Profil
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:

if (niečo) :

else :

endif; //niečo
Najmä v zmiešanom kóde php + html je to podstatne výrečnejšie, než jedna zložená zátvorka ;-)
panther
Profil
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.
Jan Tvrdík
Profil
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
Profil *
panther:Jan Tvrdík, panther, Tori, Giga:

Vdaka za reakcie
Cely problem je to ze mam v kope HTMl aj PHP.
Komentare pouzivam napr // endif alebo //endswicht ...

Ono by to clenenie kodu nebol mozno az taky problem ale ked mam v kope HTML + PHP + JS + SQL dotazy tak je to trosku gulas.

Obe tyto vrstvy by mely byt od sebe oddelene.
panther: pri tomto by som sa chel opytat ako potom tvorit stranku ked naprillad potrebujem do hotovej sablony HTML vlozit neakyvypis z databaze ?

vdaka
M.
panther
Profil
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
Profil *
panther:

kazu stranku mam tvorenu asi takymto stylom

<?php
require_once ('../conect.php');
$titul_stranky = "Administrácia - Objednávky";
include_once ('sablony/hlavna_administracia_hlavicka.html');
?>
<!---------- telo stranky --------->

Obsah tvoreny HRML + PHP + SQL

<!---------- patka stranky --------->

<?php
include_once ('sablony/hlavna_administracia_patka.html');
mysql_close();?>

Robim to takto spravne ?

M.
panther
Profil
Monkeys:
spravne to neni (z hlediska udrzby, zejmena vetsich projektu), ael pokud ti to takhle vyhovuje, proc ne.
Jan Tvrdík
Profil
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ř.
require __DIR__ . '/../connect.php'; // v PHP < 5.3 je nutné místo __DIR__ psát dirname(__FILE__)

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:

<?php
// soubor, který se postará o připojení k databázi, definici společných funkcí...
require_once __DIR__ . '/common.php';

// PHP + SQL
$orders = getOrders(...);
...

// Volání tebou napsané funkce renderTemplate, která vykreslí danou šablonu
// s danými parametry s použitím nějakého šablonovacího systému.
renderTemplate('adminitrace/objednavky.tpl', array(
    'title' => 'Administrace – Objedávky',
    'orders' => $orders,
));
Monkeys
Profil *
Jan Tvrdík:
Dakujem potreboval som postrcit neakym smerom a zmenit trochu strukturu svojho kodu

Chce to prax ze :)

M.


Este sa chcem opyta aky je rozdiel medzi objektovym programovanim a (neviem ako to nazvat) normalnym ?
Ma objektove programovanie v PHP neake lepsie vysledky viem ze sa to lisi deklaraciami Class ac nic.

vdaka
M.
Jan Tvrdík
Profil
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ě.
Lamicz
Profil
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...
Ugo
Profil
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í.

Vaše odpověď

Mohlo by se hodit

Odkud se sem odkazuje


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: