PHP closing tag
 

Nađoh ovo u dokumentaciji CodeIgniter, pa sam napokon shvatio odakle trend da se ne zatvara php tag:

Znači preporuka Code Igniter je da se ne zatvara PHP tag? Meni to zvuči prilično čudno, iako razlog možda i ima smisla (naročito za brljive koji ne paze).

Hm... Izostavljanje zatvarajućeg php taga nije baš poteklo od CodeIgnitera. Takve preporuke se mogu naći i u Zend Framework dokumentaciji i na mnogim drugim mestima a i zaista dugo se vodi rasprava da li je njihovo izostavljanje u stvari prednost ili mana. I pored toga što postoje manje više dobri razlozi za njegovo izostavljanje (može recimo u kombinaciji sa "whitespace" znacima da prekine baferovanje izlaza, poništi posebno generisane headere itd.) nikada do sada nisam imao potrebu da bilo kada radim sa takvim kodom niti lično imam običaj da izostavljam zatvarajući tag jer smatram da sve što ima otvarajući mora da ima i zatvarajući tag.

Isto stoji u Zend framework dokumentaciji. Govori se dakle o fajlu koji sadrži samo php kod. Međutim ovo je po meni žešća glupost, kao i pola zend coding standarda doduše :1064:. Mislim veća je nebuloza gledati fajl i pitati se da li on stvarno tako treba da se završi ako ne vidim closing tag, nego što će mi u tamo nekom slučaju smetati extra whitespace. Računam da ako krenem da otvaram a ne i da zatvaram tagove, neće na dobro da izađe.

Najsmešnije u vezi takvog koda je kada neko od kolega dođe da se konsultuje samnom da kojim slučajem source kod nekog php fajla nije loše preuzet pa da je naprasno prekinut u sred downloada :1046:

Pa i nije najsmešnije, a i ne dešava se toliko retko da se prekine upload ili download pa se ne iskopira ceo file, taj closing tag je sasvim dobar pokazatelj da li je sve tu ili možda ima još nešto što nedostaje.

Zend framework ustvari ne da preporučuje, nego čak zabranjuje zatvaranje php taga u fajalovima koji sadrže samo php kod:
http://framework.zend.com/manual/en/...ormatting.html

Mislim da to nema baš nekog smisla, sa jedne strane, nekako je vrlo logično da svaki otvoreni tag treba da bude i zavoren, a sa druge strane, to je nakaradno "rešenje" problema, jer nije problem u zatvorenom tagu, nego outputu pre headera (a ovo je ionako samo jedan od načina da se to desi).

Ako ce ne koriscenje closing tag-a smanjiti glavobolju, onda ga ne treba koristiti. A kao indikator zavrsetka fajla moglo bi da se stavi neki komentar tipa "//end", tako da kada neko drugi gleda fajl moze da zna da je ceo fajl tu.

..a mogle bi i devojke da se oblace i ponasaju kao muskarci, ali na celu da napisu da su devojke cisto da se zna ;-)

I meni se to ne svidja i nisam usvojio to pravilo. Oni u CI kazu 'nemoj koristiti ?> vec koristi /* end of file ali se to meni ne svidja tako.

Pristojan jezik bi trebalo da se buni kad mu se uvali takva prljavština poput nezatvorenog taga.

Zanimljivo je to sa closing tagom, nisam znao, ali mi se u svakom slučaju ne sviđa nezatvaranje taga.

Nisam ni ja znao, čak sam išao i kao ludak dodavao ?> na kraju svakog fajla jer neki ljudi sa kojima radim to ne rade, zato me je i zainteresovalo zašto to rade. Bio sam siguran da su pronašli tu "mudroliju" na nekom blogu nekog "stručnjaka", a ono code igniter.

Mene dodatne beline najviše nerviraju kada šaljem header location, pa mi javi grešku da je "header alredy sent" zbog neke beline u nekom tamo inkludovanom fajlu... :(

Ali i pored toga, ne bih bio spreman da se odreknem zatvaranja PHP taga. :)

Zato se uvek i koriste ob_ funkcije, tada ne zavisiš od toga da li je neko brljao ili drži uredan kod.

Yeap, vremenom sam provalio da je čišćenje bafera pre slanja hedera najbolji način da se izbegnu takvi problemi. A isto tako sam se vremenom disciplinovao da ne ostavljam beline posle closing taga. :)

Kada bih odlučio da napravim framework "za raju", verovatno bih i ja razmišljao koji su najčešći problemi i pokušao da smislim neko rešenje da me što manje smaraju korisnici. Možda bih i došao do iste stvari ali ne sviđa mi se rešenje koje ruši logiku da bi udovoljio "brljivim" programerima.

Meni je dovoljno da vidim ovo: "Indentation should consist of 4 spaces. Tabs are not allowed." pa da pomislim "ma 'ajde?". Daleko su fleksibilniji TAB-ovi. Neko je navikao na 2 space, neko na 4, neko na 8, zašto bi neko nekome određivao koliki indent će da koristi, kada možemo u slučaju da koristimo TAB-ove svako u svom editoru namesti TAB=N spaces i da svako gleda kako mu odgovara.

da, to sa tabovima me uzasno nervira... mada opet najgore je kad se pomesaju, pa neko koristi malo spejsove, malo tabove, onda nastane haos..

Mene nerviraju spejsovi umesto tabova al šta ćeš, svakog nešto nervira.

Trebate da koristite neki dobar editor koji ume da formatira otvoreni fajl prema vašim pravilima.

I onda je potpuno nebitno da li je čovek pre vas koristio tabove ili šta već, da li je pisao if sa { u istoj liniji ili je { u sledećoj, itd.

Zato je recimo Polystyle zlata vredan. Pre prepravke koda se "istrenira" da zapazi najbitnije šablone formatiranja izvornog koda i napravi profil a nakon završene ispravke sve se vrati na staro sa sačuvanim profilom. Naravno ovo važi samo u slučaju da u početnom kodu postoje šabloni formatiranja :)

Ima naš narod jednu poslovicu: skuplja dara nego mera :) Po meni, ako se radi u timu, prvo se dogovori o coding standardima pa se tek onda napiše prvi red koda. A ako radiš sam - sve ti je dozvoljeno.

Ne znam na šta misliš tačno, npr. NetBeans i Visual Studio to rade rutinski (formatiranje). Otvoriš neki fajl, udariš kombinaciju tastera i to je to.

Mislio sam tu više na formatiranje, ne baš na coding standarde, ali i za to ima leka, bar kod pomenutih platformi ili okruženja - postoje zvanične preporuke, a postoje i dodaci koji onda očas posla overe da je (preporučeni ili dogovoreni) standard ispoštovan.


Znači imam i ja jednu narodnu: bez alata nema ni zanata :)

Isto rade Aptana(koja je bazirana na eclipse-u) i Eclipse..

Yup, i PHPEdit ima tzv. "code beautifier" koji formatira kod onako kako poželimo :)

@degojs: nismo se razumeli, ok je to za alate, nego treba napraviti dogovor o svemu pre početka i onda nema potrebe za nekim super-alatima kao što je opisao holodoc. Koji je to timski rad ako svako radi šta hoće i kako hoće?

Kažeš "Otvoriš neki fajl, udariš kombinaciju tastera i to je to." I onda sačuvaš, pa onda neko drugi uradi to isto, pa neko treći to isto i na kraju dođete do revizije 14 a niko ništa nije menjao nego je samo hteo da "baci pogled".

Ako ćemo iskreno, današnji editori sve manje donose noviteta vezaih za samo kodiranje, a sve više glavnih features su vezani za kozmetiku, odnosno "beautifying the code" i onda editori rade 40% sporije da bi mogli da progutaju svačije coding styles i kako kaže holodoc: "istrenira" da zapazi najbitnije šablone formatiranja izvornog koda i napravi profil a nakon završene ispravke sve se vrati na staro sa sačuvanim profilom... Super što može ali to je bacanje resursa i vremena koje može da se preči običnim "old-school" dogovorom. )

Ma.. a šta da radiš kad se to desi, oćeš da se natežeš i da ti još neko kaže, e ajd ne smaraj više, nisi ti šef.. itd.

Pa nećeš da radiš checkin ako si samo gledao ;-)

E sad za resurse, kao smorićeš taj dual ili quad-core sa tim što će da protrči kroz fajlove? Iskreno, meni su takvi alati baš baš time saver.

Recimo imaš neke (besplatne) dodatke za VS koji rade baš kontrolu coding standarda (a pravila naravno mogu da se podese, obično na nivou firme) i to je baš super - pravilo je da nema checkina ako ovaj prijavi probleme i slično. Cenim da su ovi u MS-u i napravili te dodatke prvo za internu upotrebu...

Pa eto vidiš, super je taj dodatak za VS, da to postoji i za druge editore - ja bih forsirao ne samo sve u timu nego i samog sebe. Ali tu se vraćamo na početak priče :)

ispada da svi ovde (me included) ne volimo izostavljanje '?>' taga
a opet, vrlo cesto se srece kao preporuka kod vecih projekata

interesantno :)

sto se tice dogovora vs all-mighty-editora
biram prvu varijantu

nekoliko puta sam morao menjati svoje navike (promena firme) ali opet radije cu naterati sebe da pisem zagrade kako projekat kaze, nego da preparsiram svaki fajl

radim na visegodishnjim projektima i trazim od projekta da ima tvrdu strukturu

Eto ja sam od tih koji u svojim projektima u CI-u izostavljam php closing tag i stavljam '// EOF'. Korektno mi deluje i sa i bez, nista cudno tu ne vidim.
Nemam nista protiv kada se tim dogovara o standardima ali mi nije korektno kada se oni bez obrazlozenja i logike namecu samo zato sto se to nekom ko namece svidja ili je navikao.

Code "beautifieri" stvarno nisu nikakavi "super" alati već poprilično korisne stvarčice koje se danas isporučuju uz svaki kvalitetniji IDE. PHPEd recimo dolazi sa podrškom za Polystyle (doduše u trial varijanti) dok Eclipse i NetBeans imaju svoja ugrađena rešenja. Postoji i dobar razlog za to. Naime, koliko god tim bio uštelovan i kakve god konvencije kodiranja da se usvoje na početku, svaki koder ima neku svoju specifičnost koje se teško odriče. Ja recimo ne mogu da smislim kod u kome nov blok koda počinje u vitičastoj zagradi u sledećem redu i te prakse se držim od kako sam ukucao prvu vitičastu zagradu u svom kodu pre sada već nešto više od 20 godina. I ne verujem da će me iko ikada naterati da drugačije pišem kod. Ako se to nekome ne sviđa što se tiče mene u redu je. Napisaću kod po mome a pred predavanje ću ga provući kroz Polystyle što je operacija koja traje sekundu-dve.

Da stvar bude gora specifičnosti se posebno osećaju u timskom radu sa strancima. Nemci su recimo bez daljnjeg najspecifičniji u pisanju koda (kada je PHP u pitanju dosta njih koristi neku vrstu mutanta između PEARa i nekih krajnje čudnih sintaksičkih "sentenci") dok recimo ima slučajeva da kod bude toliko loš da ništa osim refactoringa ne preostaje.

Zato code "beautifieri" nisu alatke koje treba potcenjivati, posebno Polystyle. Neki ih ne vole ali nepobitna je činjenica da jednim potezom može da se postigne potpuna doslednost jednom istom načinu formatiranja koda tj. izbegla karta u jednom pravcu za Golgotu kada nalogodavac posla zakuca na vrata :)
Većina klijenata za CVS i SVN danas ima opciju pregleda sadržaja revizija direktno iz repozitorijuma tako da ne vidim zbog čega bi neko radio check-in za materijal koji može direktno da se pogleda u repozitorijumu. SVN recimo podržava ovu opciju i bez nekih specijalnih klijenata (za one koji su više privrženi konzoli) a odlična alternativa korisnicima na Widnowsu je TortoiseSVN.
Slažem se da neka razvojna okruženja imaju gomilu funkcionalnosti koje realno nisu potrebna krajnjim korisnicima ali definitivno se ne slažem da nije potrebno imati alatke u okviru editora koje omogućavaju "održavanje higijene" koda kao što sam to već objasnio u prethodnom delu ovoga posta. Vodeći se tom logikom ispašće da su i sintaksno obeležavanje koda, indentacija i sličen stvari takođe luksuz što je po meni opet potpuna krajnost :) Da ne budem pogrešno shvaćen, kao i svako ko ima nameru da živi od svojih projekata, volim brze i pre svega upotrebljiva razvojna okruženja tako da na Windows baziranim platformama kada je PHP u pitanju moj izbor pada na PHPEd. Na Linuxu nažalost postoji samo jedna dostojna zamena za koju može da se kaže da je upotrebljiva a to je po meni PDT.

Uostalom koga ne mrzi može da pročita jednu od mojih skorašnjih tekstova na temu razvojnih PHP okruženja (link). Tekst je malo stariji ali generalno nema nekih preteranih razlika u odnosu na nove verzije.

"Potcenjivati"? "Nije potrebno"? Ti si nešto pogrešno razumeo u mom postu. Potrebno je, i to baš zbog ljudi koji imaju takav stav kao ti :) Evo i zašto tako mislim: ako već dođe do toga da moraš da uptrebljavaš te alate i pored svih dogovora, onda džabe i dogovor - neka radi ko šta hoće i kako hoće. A ako niko ne može nekoga naterati da promeni navike - onda je taj solista i takav stav nije za bilo kakav timski rad. A ako nema timskog rada, i sve radiš sam - onda ti ti alati nisu ni potrebni jer je sav kod tvoj i nema "konflikta". Dakle, paradoks :D

Ne bavim se paradoksima jer su previše rekurzivni ;)

Što se tiče pitanja "dogovora"... Jedno je kada kompanija ima takvu poslovnu politiku da svakom junior developeru dodeli mentora koji će biti zadužen za uvođenje "junoše" u sitna crevca i uklapanje u svoje izolovane razvojne timove a potpuno drugo je realnost u kojoj se dešava da na projektu sarađuje nekoliko kompanija, neretko iz različitih država, gde svaka ima svoja ustaljena pravila i načine rada. Šta onda? Poslodavac kaže da posao mora da se odradi a njegov razvojni tim kuka kako će verovatno biti problema jer postoje neke neusklađenosti oko formatiranja koda :1092:

Još gore ako se radi na projektu gde se više postojećih različtih projekata uklapa u jednu celinu. Ako nije potrebno "prčkati" po postojećem kodu i njegova enkapsulacija "drži vodu" onda u redu, ne treba poprvljati ono što nije pokvareno. Međutim, ako treba zavrnuti rukave teško da ima profesionalca koji nije osetio čari refactoringa i "ulepšivača koda" ;)

"You’re not here to write code; you’re here to ship products!"

Razlog je CI celo izvrsavanje koda stavlja u ob_start/ob_end_flush, kreira prvo celu stranicu i tek na kraju salje headere i sadrzaj. E sad, ako bi se nedge potkrao taj enter iza ?> na kraju fajla, pucale bi neke stvari. Dakle, razlog je interni mehanizam kako framework radi (bar tako kazu u CI dokumentaciji).

E sad, zasto imati Enter na kraju fajla je vec drugo pitanje. Neki editori ga dodaju automatski, a neki version control sistemi po defaultu javljaju warning za to. Bas iz razloga sto je tekstualni fajl koji nema enter na kraju sumnjiv, kao da nije kompletan.

Licno, meni se svidja preporuka CodeIgnitera da se koristi // EOF ili neka slicna oznaka, pa sam poceo da koristim to i kada radim van CIa. Nekako mi kod izgleda lepse u editoru ;)