DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Ja oké, daar ben ik het mee eens. In een simpele methode kan je wel een variabele als $x hebben. Maar als het over meerdere methodes gebruikt wordt wil ik gewoon zien wat het hoort te bevatten. Bijvoorbeels als je $uc hebt wat null bevat, terwijl het een object hoort te bevatten. Dat zie je echt niet aan de variabele. $userCollection is in dit geval vele male beter, dat moet je met me eens zijn.
Het scheelt zoveel met het debuggen van een 'vreemd' script dat je weet wat de variabele hoort te bevatten. Dit geldt niet enkel voor PHP, maar voor alle programmeertalen.
Het scheelt zoveel met het debuggen van een 'vreemd' script dat je weet wat de variabele hoort te bevatten. Dit geldt niet enkel voor PHP, maar voor alle programmeertalen.
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.
Op dinsdag 13 augustus schreef Xa1pt:
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
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...
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...
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 vertalenquote:
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.
En dat die Human Readable Code verder gaat dan if/else statements, dat begrijp ik ook wel, ik hoef toch niet overal een voorbeeld van te geven. Het is alleen dat er zat mensen zijn die die code zo erg hanteren dat het alsnog niet meer leesbaar is omdat het overdrijven of dat ze meteen in de aanval gaat als iets lames niet klopt.
En ja, ik heb aan grote projecten gewerkt, vele malen groter dan 100k LOC. En het is zo vervelend als je steeds onnodig volledige woorden aan het tikken bent.
Dat laatste doelde ik dus op.quote:
[..]
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.
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
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
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:
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:
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
Het volledig uitschrijven kan ook overdreven worden. Ik weet nog dat ik aan een project verder moest werken waarin de variabele vaak ontzettend lange namen hadden. Waarvan ik oa deze twee nooit zal vergeten:
$OrganizationalScheduleIdentificationCode
$OrganizationalScheduleIdentificationName
het ID en de naam van het rooster. Twee variabele die vaak terug kwamen in het programma...
Lang leve een goede IDE met fatsoenlijke completion 
De langste die ik zo snel zie in mn recente projecten is de $shopOrderBillingLocationCountryId...
De langste die ik zo snel zie in mn recente projecten is de $shopOrderBillingLocationCountryId...
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 wat een string is zou ik de variablename anders noemen.
$d zou ik uiteraard anders noemen.
De date functie is met een hoofdletter, moet volgens mij met een kleine "d".
In de date functie mist een string. De letters moeten in een string staan.
De letters in de date functie kloppen niet. Y is 4x een getal.
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.
De "d" in de if statement mist een dollar teken.
Aan gezien er niets onder de "}" in php, zou ik de "?>" weglaten.
Dankzij kennis van Java en andere programmeertalen, zie je gewoon dat PHP echt lelijk is. Java is ook niet mooi.
date() geeft gewoon een string terug en === heeft daar geen toegevoegde waarde.quote:
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.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Je mist de belangrijkste: Het hele concept is flawed aangezien je een datum string vergelijkt op gelijkheid waardoor je na de betreffende datum gewoon weer krijgt dat je kan leren. Wel waarschijnlijk in dat geval voor je hertentamen....
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
Ik zou het gewoon in één regel doen
| 1 | <?=date('dmY')=='070113'?"We are Screwed dude!":"Nog tijd om te leren voor proeftentamen :)" ?> |
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
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:
[..]
Ik zou een class maken. Ware het niet dat PHP dat al doet: http://php.net/manual/en/book.datetime.php
En dan heb ik het helemaal nog niet over zaken als een beetje fatsoenlijke tijdzone berekeningen. Je wil niet weten wat voor ongelooflijk vreselijke code ik daar niet voor heb moeten schrijven... (Application wide de tijdzone default veranderen, datum setten en dan restoren. yay! Er is wel een setTimezone functie maar die werkte dacht ik slechts 1 kant op.)
*edit:*
Vergelijken lijkt nu wel mogelijk te zijn, het is alleen niet gedocumenteerd dat het kan. Ook zo leuk.
Naja ik gebruik Zend_Date maar tegenwoordig.
http://php.net/manual/en/class.datetime.php
PHP5.2.2, reden we toen nog op dinosaurussen of al op paarden?
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 ==).
PHP5.2.2, reden we toen nog op dinosaurussen of al op paarden?
Omg idd. En ik heb het zowaar ook in de changelog gevonden:
Echt weer typisch PHP met zijn vele uitzonderingen want volgens mij is DateTime de enigste die het kan?
Thats all wat er over staat...quote:Fixed bug #40961 (Incorrect results of DateTime equality check). (Mike)
Echt weer typisch PHP met zijn vele uitzonderingen want volgens mij is DateTime de enigste die het kan?
Omzetten naar timestamp.quote:
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?
Timestamp1-timestamp2=verschil
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik hou zoveel van jou, ik doe alles voor je! O+
Datetime lijkt me het beste persoonlijk 
Op dinsdag 13 augustus schreef Xa1pt:
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
op de achtergrond is het.allemaal timestamp...quote:
Datetime lijkt me het beste persoonlijk
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik hou zoveel van jou, ik doe alles voor je! O+
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:
[..]
je gaat me niet met droge ogen vertellen dat je dat handiger vind dan datetime->diff()
Op dinsdag 13 augustus schreef Xa1pt:
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
