1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | <?php //if the post has a parent if($post->post_parent){ //collect ancestor pages $relations = get_post_ancestors($post->ID); //get child pages $result = $wpdb->get_results( "SELECT ID FROM wp_posts WHERE post_parent = $post->ID AND post_type='page'" ); if ($result){ foreach($result as $pageID){ array_push($relations, $pageID->ID); } } //add current post to pages array_push($relations, $post->ID); //get comma delimited list of children and parents and self $relations_string = implode(",",$relations); //use include to list only the collected pages. $sidelinks = wp_list_pages("title_li=&echo=0&include=".$relations_string); }else{ // display only main level and children $sidelinks = wp_list_pages("title_li=&echo=0&depth=1&child_of=".$post->ID); } if ($sidelinks) { ?> <h2><?php the_title(); ?></h2> <ul> <?php //links in <li> tags echo $sidelinks; ?> </ul> <?php } ?> |
else bestaat helemaal niet in PHP! Wat dom zeg.quote:Op vrijdag 4 januari 2013 00:03 schreef Scorpie het volgende:
[ afbeelding ]
Spot de 10 fouten. En dit is dan HBO niveau.
Mooiste is dat je dan met verbeteringen aankomt en je gewoon opmerkinge naar je hoofd krijgt als 'ik heb een hekel aan mensen die zich willen bewijzen'quote:Op vrijdag 4 januari 2013 00:09 schreef Juicyhil het volgende:
[..]
else bestaat helemaal niet in PHP! Wat dom zeg.
Wow, bedoel je dat dit afkomstig is van 'n docent?quote:Op vrijdag 4 januari 2013 00:11 schreef Scorpie het volgende:
[..]
Mooiste is dat je dan met verbeteringen aankomt en je gewoon opmerkinge naar je hoofd krijgt als 'ik heb een hekel aan mensen die zich willen bewijzen'
Is niet zo moeilijk om dat te doen met zulke crappy code he.
Nee joh, een student die zichzelf application developer/webdesigner noemt.quote:Op vrijdag 4 januari 2013 00:11 schreef Diabox het volgende:
[..]
Wow, bedoel je dat dit afkomstig is van 'n docent?
En ik quote:quote:
Ja sorry, ik ben allergisch voor kut code. Dan krijg ik spasmes en moet ik het proberen te herstellen. My bad.quote:"btw... heb een hekel aan mensen die zichzelf hoe-dan-ook proberen te bewijzen. Just keep it for yourself."
Is niet je beste vriend neem ik aan.quote:Op vrijdag 4 januari 2013 00:17 schreef Scorpie het volgende:
[..]
En ik quote:
[..]
Ja sorry, ik ben allergisch voor kut code. Dan krijg ik spasmes en moet ik het proberen te herstellen. My bad.
quote:is volgens mij gewoon een nette manier hoor? Waarom een ferarri bouwen als ik met een fiat punto mn boodschappe kan doen?? Lol koop een taart en vier het ben trotts op je dat je de fouten kon ontdekken
Nee niet echt. Ik noemde zijn code ook dramatisch, misschien dat dat er iets mee te maken heeft.quote:Op vrijdag 4 januari 2013 00:19 schreef Diabox het volgende:
[..]
Is niet je beste vriend neem ik aan.
Heb ik ook een hekel aan, slordige code. Variabelen als $p en $u, verkeerde inspringingen, verkeerd commentaar blergh.quote:Op vrijdag 4 januari 2013 00:19 schreef Scorpie het volgende:
[..]
Nee niet echt. Ik noemde zijn code ook dramatisch, misschien dat dat er iets mee te maken heeft.
Human Readable Codequote:Op vrijdag 4 januari 2013 00:24 schreef Fusioxan het volgende:
[..]
Heb ik ook een hekel aan, slordige code. Variabelen als $p en $u, verkeerde inspringingen, verkeerd commentaar blergh.
Ik wil, dat ik aan de naam van de variabelen kan zien wat het kan/hoort te bevatten. Helaas zijn er wat medestudenten het oneens met mij...
Bespaart je wel geheugen en schijfruimtequote:
zolang het geen globale variabele zijn, maar alleen een variabele binnen een functie, zie ik het probleem niet. Een gemiddeld mens kan best onthouden wat er in de variabele zit.quote:Op vrijdag 4 januari 2013 00:24 schreef Fusioxan het volgende:
[..]
Heb ik ook een hekel aan, slordige code. Variabelen als $p en $u, verkeerde inspringingen, verkeerd commentaar blergh.
Ik wil, dat ik aan de naam van de variabelen kan zien wat het kan/hoort te bevatten. Helaas zijn er wat medestudenten het oneens met mij...
Ja en nee, in sommige talen heeft de lengte van je variabel naam geen invloed op geheugen gebruik. Schijfruimte gebruik uiteraard wel, maar voor ontwikkeling is het wel handig dat je je eigen code kunt begrijpen. Daarnaast kun je er later obfuscator software overheen gooien die alle variabel- en functienamen. Bv $post_date_gmt = $wpt1 en wpt_mashup_create_answers_post = fwpt1. Je code die je uiteindelijk gaat gebruiken zal minder in schrijfruimte innemen en security through obscrutity is een bijkomend voordeel.quote:Op vrijdag 4 januari 2013 08:35 schreef Juicyhil het volgende:
[..]
Bespaart je wel geheugen en schijfruimte
De code stijl (else wel of niet op een nieuwe regel) is wel iets heel anders als je variabele benaming. Wat mij betreft knal je er 10 enters tussen, zolang het maar consistent gebeurd volgens de afgesproken stijl.quote:Op vrijdag 4 januari 2013 09:34 schreef Maringo het volgende:
[..]
zolang het geen globale variabele zijn, maar alleen een variabele binnen een functie, zie ik het probleem niet. Een gemiddeld mens kan best onthouden wat er in de variabele zit.
Het is gewoon kansloos om elke variabele uit te schrijven waar het voor staat. Dat maakt je code alleen maar onoverzichtelijk en rommelig.
Het hele idee Human Readable Code (of elke andere benaming ervoor) is ook ver over de top gegaan. Dat er standaarden zijn in de benamingen van functies ( fetchVariabels() of fetchVars() ipv fVar(), func38() of thx() ) dat kan ik helemaal begrijpen, maar dat het als 'fout' gezien wordt als je de else of elseif op een nieuwe regel begint ipv op dezelfde regel als de } van de vorige is gewoon onzin.
Als je 100k LOC aan code hebt die niet object georiënteerd is, dan moet je het al per definitie weggooien. Daarnaast ben ik het wel met het punt eens dat je soms $temp variabelen kunt gebruiken die kwa naam weinig zeggen wat ze precies hebben, maar in hun context perfect duidelijk zijn.quote:Op vrijdag 4 januari 2013 13:57 schreef StM het volgende:
[..]
De code stijl (else wel of niet op een nieuwe regel) is wel iets heel anders als je variabele benaming. Wat mij betreft knal je er 10 enters tussen, zolang het maar consistent gebeurd volgens de afgesproken stijl.
Dat je nu nog weet wat var $x betekend is leuk, maar weet je collega of jijzelf het over een jaar of 2 jaar ook nog steeds? Je hebt duidelijk nooit gewerkt aan projecten van meer dan 100k LOC over duizenden bestanden. Je kan en wil dan echt niet meer na gaan moeten denken over wat iets doet en wat er in zou kunnen zitten. Dan wil je gewoon zien $oActiveUserCollection ipv $uc.
Globale variabelen (op je superglobals na) zijn trouwens per definitie evil.
Human Readible Code is zoveel meer dan een if/else statement definitie. Leuk dat jij onthoudt dat $p staat voor Person en $u voor Unit, degene die over 3 jaar jouw code gaat updaten weet dat niet.quote:Op vrijdag 4 januari 2013 09:34 schreef Maringo het volgende:
[..]
zolang het geen globale variabele zijn, maar alleen een variabele binnen een functie, zie ik het probleem niet. Een gemiddeld mens kan best onthouden wat er in de variabele zit.
Het is gewoon kansloos om elke variabele uit te schrijven waar het voor staat. Dat maakt je code alleen maar onoverzichtelijk en rommelig.
Het hele idee Human Readable Code (of elke andere benaming ervoor) is ook ver over de top gegaan. Dat er standaarden zijn in de benamingen van functies ( fetchVariabels() of fetchVars() ipv fVar(), func38() of thx() ) dat kan ik helemaal begrijpen, maar dat het als 'fout' gezien wordt als je de else of elseif op een nieuwe regel begint ipv op dezelfde regel als de } van de vorige is gewoon onzin.
Consistentie is imo vrijwel net zo belangrijk als duidelijk zijn in wat je doet. Dus ook je temp vars duidelijk defineren. Maar goed, ook ik heb zo mijn uitzonderingen (meestal $i, $k en $v). Echter zijn die uiteraard wel zeer beperkt in hun scope.quote:Op vrijdag 4 januari 2013 14:28 schreef Pakspul het volgende:
[..]
Als je 100k LOC aan code hebt die niet object georiënteerd is, dan moet je het al per definitie weggooien. Daarnaast ben ik het wel met het punt eens dat je soms $temp variabelen kunt gebruiken die kwa naam weinig zeggen wat ze precies hebben, maar in hun context perfect duidelijk zijn.
Ook hier is consistent zijn weer belangrijk. Er kunnen wel degelijk redenen zijn om Nederlands jargon in je naamgeving te gebruiken. Vaak omdat domeinspecifiek taalgebruik heel lastig te vertalen kan zijn en dat eigenlijk niemand daarna nog weet wat het nu exact moet zijn. Maar NOOIT mixen (en voor iets als rijden is het taalgebruik zo algemeen dat dat imo nooit te verantwoorden valt om te vertalen )quote:Op vrijdag 4 januari 2013 14:39 schreef Fusioxan het volgende:
Wat ik me ook zo aan erger, engels en nederlands programmeren... Ik herinner me het net, want p staat in ons huidige programma voor positie (ja, oké, het is JAVA, maar dat moet van school).
Dan beginnen ze weer over een klasse Rijden met als methodes: forward(), leftTurn(), rightTurn(), parkeren(), uitparkeren(). Om het netjes te zeggen, om van te kotsen...
Ik heb het niet perse over 1 letterige variabele, ik bedoel meer dat het onnodig is om binnen een functie (dus niet je de vars die je over meerdere functies en/of classes gebruikt) variabelenaam te gebruiken als $ActiveUserCollection terwijl je het ook kan afkorten tot $ActUsrColl.quote:Op vrijdag 4 januari 2013 14:34 schreef Scorpie het volgende:
[..]
Human Readible Code is zoveel meer dan een if/else statement definitie. Leuk dat jij onthoudt dat $p staat voor Person en $u voor Unit, degene die over 3 jaar jouw code gaat updaten weet dat niet.
Dat laatste doelde ik dus op.quote:Op vrijdag 4 januari 2013 14:44 schreef StM het volgende:
[..]
Consistentie is imo vrijwel net zo belangrijk als duidelijk zijn in wat je doet. Dus ook je temp vars duidelijk defineren. Maar goed, ook ik heb zo mijn uitzonderingen (meestal $i, $k en $v). Echter zijn die uiteraard wel zeer beperkt in hun scope.
Terug komend op je consitentie punt van paar posts hier boven. Als je met je team/of jezelf afspreekt dat List altijd een lijst met bepaalde objecten is dan kun jet met gemak $userList, gebruiken. Bij afkortingen zou ik oppassen, als ze duidelijk zijn dan kun je er voor gaan, anders eerste definitie comment plaatsen.quote:Op vrijdag 4 januari 2013 14:56 schreef StM het volgende:
Afkorten naar $ActUsrColl is toch ook prima? Als jullie dat maar afgesproken hebben. Ik ben zelf meer van het volledig uitschrijven maar ik zou ook zonder problemen switchen naar een project waar ze een kortere namen gebruiken die nog steeds beschrijven wat er in zit.
Je reageerde alleen op een post met 1 letterige vars en die zijn een echte nogo imo net als de vele andere niets zeggende namen die je kan bedenken
Dat ben ik met je eens.quote:Op vrijdag 4 januari 2013 14:56 schreef StM het volgende:
Afkorten naar $ActUsrColl is toch ook prima? Als jullie dat maar afgesproken hebben. Ik ben zelf meer van het volledig uitschrijven maar ik zou ook zonder problemen switchen naar een project waar ze een kortere namen gebruiken die nog steeds beschrijven wat er in zit.
Je reageerde alleen op een post met 1 letterige vars en die zijn een echte nogo imo net als de vele andere niets zeggende namen die je kan bedenken
Eens zien...quote:Op vrijdag 4 januari 2013 00:03 schreef Scorpie het volgende:
[ afbeelding ]
Spot de 10 fouten. En dit is dan HBO niveau.
date() geeft gewoon een string terug en === heeft daar geen toegevoegde waarde.quote:Op vrijdag 4 januari 2013 17:11 schreef Qunix het volgende:
De if statement is een vergelijking tussen een string en een date. Dit als programmeur zou ik niet doen.
De if statement kan een === gebruiken.
Ik zou een class maken. Ware het niet dat PHP dat al doet: http://php.net/manual/en/book.datetime.phpquote:Op vrijdag 4 januari 2013 17:18 schreef mstx het volgende:
[..]
date() geeft gewoon een string terug en === heeft daar geen toegevoegde waarde.
Overbodige codequote:Op vrijdag 4 januari 2013 17:20 schreef Qunix het volgende:
[..]
Ik zou een class maken. Ware het niet dat PHP dat al doet: http://php.net/manual/en/book.datetime.php
1 | <?=date('dmY')=='070113'?"We are Screwed dude!":"Nog tijd om te leren voor proeftentamen :)" ?> |
quote:Op vrijdag 4 januari 2013 17:24 schreef mstx het volgende:
[..]
Overbodige code
Ik zou het gewoon in één regel doen
[ code verwijderd ]
Die alleen vrijwel niemand gebruikt omdat nog steeds basis dingen als 2 datums met elkaar vergelijken niet kan...quote:Op vrijdag 4 januari 2013 17:20 schreef Qunix het volgende:
[..]
Ik zou een class maken. Ware het niet dat PHP dat al doet: http://php.net/manual/en/book.datetime.php
staat er gewoon bij hoorquote:Changelog
Version Description
5.2.2 DateTime object comparison with the comparison operators changed to work as expected. Previously, all DateTime objects were considered equal (using ==).
Thats all wat er over staat...quote:Fixed bug #40961 (Incorrect results of DateTime equality check). (Mike)
Omzetten naar timestamp.quote:Op vrijdag 4 januari 2013 18:06 schreef StM het volgende:
Omg idd. En ik heb het zowaar ook in de changelog gevonden:
[..]
Thats all wat er over staat...
Echt weer typisch PHP met zijn vele uitzonderingen want volgens mij is DateTime de enigste die het kan?
op de achtergrond is het.allemaal timestamp...quote:Op vrijdag 4 januari 2013 18:33 schreef Scorpie het volgende:
Datetime lijkt me het beste persoonlijk
je gaat me niet met droge ogen vertellen dat je dat handiger vind dan datetime->diff()quote:Op vrijdag 4 januari 2013 18:27 schreef Juicyhil het volgende:
[..]
Omzetten naar timestamp.
Timestamp1-timestamp2=verschil
Idd, die gebruik ik vaak.quote:Op vrijdag 4 januari 2013 18:39 schreef KomtTijd... het volgende:
[..]
je gaat me niet met droge ogen vertellen dat je dat handiger vind dan datetime->diff()
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |