Znači sljedeći code:
function test($x,$y,$z='miki')
{
if($z=='miki')
{
$z=0;
if($z=='bilo_sto...')
{
echo 'this is bug??';
}
}
}
test(1,2);
Dali će poziv test funkcije na način test(1,2) uzrokovati da se ispiše ‘this si bug??’ …ili se nebi trebalo navedeno ispisati?
Hmm…
Trebala mi je minuta da skuzim sta tvoj kod uopce radi, ovo je uvjerljivo naj ne citljiviji stil indentanja koji sam vidio 
Anyway, kod je ispravan, trebalo bi se ispisati ‘this is bug??’.
Zasto? Zato jer koristis == umjesto === za uspredbu (gotovo nikada dobra ideja). == ce u slucaju da varijable nisu istog tipa napraviti typecasting. U tvom konkretnom slucaju, on trazi intval stringa ‘bilo_sto…’, a to je 0, i na kraju dobijes da je 0 == 0 sto je i istina.
Rijesenje: koristi === za uspredbu, tu i svugdje, vrlo rijetko ti treba ==. I da, daj te zagrade pisi da se mogu procitati, pliz 
Hvala na objašnjenju, a što se tiče identanja…ja ovako vidim odlično jer tako oduvijek radim. I kad gledam code koji nije tako identan…nađem se u tvojoj poziciji, puno teže vidim. A jbg…počeo sam ovako sa identanjem od pythona, gdje zagrade nisu bile potrebne…samo obvezno identanje…i kad su došle zagrade, nastavio sam ovako… Nebi mjenjao ni u ludilu, meni je ovo sto puta preglednije.
A što se tiče primjera… koliko sam ja znao (tj.mislio)…da === uspoređuje i jednakost po vrijednosti i jednakost po tipu varijable , dok == samo jednakost po vrijednosti.
Logično onda:
0==false ? -> true
0===false ? -> false
Ovo gore mi nebi palo na pamet da se gleda ovako…kad je 0 u startu false, a string u startu true 
Dobro si i mislio, jedino sto == radi typecasting, ali ne sve u boolean, nego ako usporedjujes nesto s brojevima, onda je sve prebaceno u brojeve.
Zato je bog isus podario svijetu PSR standard: http://www.php-fig.org/psr/psr-2/
Ti to radis na nacin na koji niko nikad nigdi nije napravio - indentas viticaste zagrade umisto da su u liniji sa metodom/petljom kojoj pripadaju. Stvarno, procita san milijune i milijune linija koda u zivotu, od tisuca razlicitih autora, ovako nesto nikad nisan nasa.
Dakle indentanje koda (ka u pythonu) - naravno i obavezno, OSIM zagrada koje prakticki oznacavaju liniju indenta u kojoj se nalazi deklaracija metode/petlje kojoj indentani kod pripada.
I usputno budi receno, u spaces vs tabs indentiranju, spejsovi u 21. stoljecu vise manje pobjeđuju, i svode se na 2-4 spejsa po tabu, kako vec ko voli, ali nikako 8.
Meni je ovo savršeno čitljiv kod. Apsolutno je jasan. Dok onaj “po standardu” mi je totalno nečitak jer ne mogu pohvatati gdje završava uvjet.
Odnosno, kod ovakvog formatiranja odmah je vidljivo gdje počinje i gdje završava, dok u onome drugome moraš tražiti iduću zagradu kako bi uhvatio što se nalazi unutar zagrada.
Taj “standardni” nema veze sa zdravim mozgom.
I puno sam toga još napravio što niko nikad nigdi nije napravio. Ponosan
Sve je to okej dok sam jedini pises i citas svoj kod, i dok ti ne smeta oci privikavat citat tuđi kod. Sam si gore reka da ti je teze citat tuđi kod. A posto zivimo u svitu u kojem je blesavo uopce pomislit sam nesto isprogramirat iz nule (zanemarujuci potpuno amaterske nebitne projektice), bez pomoci frameworka, librarya, ovog onog komada tuđeg koda, pametan covik se nauci prilagodit svitu oko sebe u svrhu podizanja vlastite ucinkovitosti.
Standardi postoje bas zato da bi se ujednacile prakse i olaksao zivot svima. I naravno da bi se izbjeglo svakodnevno mjerenje ciji je veci izjavama poput “taj nacin nema veze sa zdravim mozgom, ja san pametniji od globalne zajednice developera”. Stvarno, bas nikad nisan vidio da neko indenta zagrade. Mislim da bi i vecina lintera na takvu sintaksu javljala gresku.
Nikakav problem, podesim framework da isporucuje layout kakav god poželiš. Development je proizvoljna identacija…production je minimizirani file ionako…
Tako da developeri međusobno nimalo ne ovise o tuđem stilu…svako udara po svome, i svatko gleda u projekt po svome odabiru.
Sve je super dok radis manje projekte ali sta kad radis projekat od pola godine - godinu onda jako dobro pazis da sve sto za 2-3 mjeseca neces znati sto je extractas u metodu citljivog imena…
Kad smo vec kod citljivosti kod po meni je dobar programer onaj koji ne mora koristiti komentare svugdje nego samo na metodama da znas sta koji var vraca i sto radi sama funckija.
Iskreno poludim kad preuzmem neciji projekat i vidim:
if($this->user->role == 'User' || $this->user->permission == 'Can Add' && $this->user->points > 50 && $this->user->points < 50
I dok shatis sta taj if radi treba ti par minuta umjesto da se ta cijela provjera extracta u neku metodu da imas:
if($this->userCanPost())
Pa sad vi recite sta je citljivije znam da je primjer glup ali poanta je tu sve sto neces znat sta je za par mjeseci extractaj u metodu zato 
Komentar pored dužeg uvjeta koji ga ukratko objašnjava nije uopće loš…gdje bi došli kad bi za svaki uvjet koji je imalo kompleksniji gradili posebnu metodu??
No, ovo gore što si pokazao se radi iz drugog razloga.
Spomenuti uvjet se najvjerovatnije neće provjeravati samo na jednom mjestu, nego na n mjesta u projektu. Upravo zbog toga ponavljanja je nadasve korisno uvjet prenesti u metodu …jer kad se jednog dana odluči nešto dodatno ugraditi u tu provjeru “može li korisnik postati”…onda će se fino doraditi samo metoda i sve će štimati svuda naokolo. U suprotnom bi trebalo tražiti po skriptama gdje sve koristimo takav složeni uvjet pazeći da nešto dodatno ne zbrkamo…
To je uglavnom glavna ideja DRY dizajna.
A sad pitanjca dva:
-dali zaista svaki svoj složeniji uvjet pretvaraš u metodu?
-ako da, s čime određuješ granicu…koliko to elemenata moraš imati u uvjetu da bi se odlučio da je uvjet zrel za dobit svoju metodu?
Je tocno je sto si reko to ne jos jedamod razloga zasto se to radi, i ne kazemda je lose staviti komentar zapravo to je stvar preferencije meni je ljepse imati lijepo opisane metode nego komentare preglednije mi je…
A radim logikom da sve sto necu moc shvatit sta radi za mjesec dva refakturiram dok ne bude jasno sta program radi. To sam pokupio od laravela proucavajuci njihov source kod.
Za taj slučaj mi se čini puno jednostavnije i prihvatljivije objasniti uvjet komentarom…nego graditi za takve uvjete dodatne metode. Jer takvih uvjeta imaš mali milijon.
S druge strane, ako si stavio kompleksni uvjet unutar svoje metode…onda opet imaš tu istu kompleksnost samo na drugom mjestu. Tako reći postigao si da ti metoda ničem drugom ne služi nego da ti bude komentar za tvoj uvjet.
Meni se tako čini da jedini opravdani razlog gradnje metoda za kompleksne uvjete je isključivo razlog što se takvi kompleksni uvjeti najčešće i ponavljaju na više mjesta. -> pa iz toga slijedi da gotovo svaki kompleksniji uvjet treba ići pod metodu, iz čega se može loše zaključiti da je uzrok nastanka metode kompleksnost uvjeta.
Jer i jednostavni uvjeti (što je rijeđe) također trebaju ići pod metodu ako se ponavljaju na više mjesta, pogotovo ako tumače određeni proces koji će vjerovatno evoluirati.
Kad bi pogledao ovaj video ( https://laracasts.com/series/code-katas-in-php/episodes/7 ) sve bi ti bilo jasnije cak mozda i cijeli serijali 
PS koji code editor koristis? Mozda ti se to cini naporno ali u php stormu odredeni dio koda extractas u 3 sekunde i jos dobis komentare i sve…
Ne radi se o napornosti, to nisam nigdje rekao. Štoviše i ja sam rekao da će skoro uvijek kompleksniji uvjet završiti pod metodom. Samo iz drugih razloga od onih koje si ti naveo. Metoda po meni ne služi da bude “komentar” uvjetu…nego da se obrazac ponašanja programa locira na isključivo jedno mjesto.
Inače koristim sublime3 i sviđa mi se
I tu se slazemo u potpunosti
Nisi vidio Python deva koji piše Javu? :]]
Ne znam znaš li, ali otprilike citiraš Uncle Boba u jednom od njegovih lekcija. Slažem se s njim u 99% svega što je rekao ili napisao, tako i s komentarima. Komentari su zli i obično dobar znak da si negdje “omašio” u dizajnu.
Ne znam ali sam gledo jako puno Jeffery Waya na laracastu i puno naucio od njega sto se tice programiranja pogotovo prave primjene OOP-a