Net en Overzichtelijk programmeren
Door Nicoow Unknown, 20 jaar geleden, 10.053x bekeken
Een tutorial over netjes en overzichtelijk programmeren in PHP
Gesponsorde koppelingen
Inhoudsopgave
Er zijn 47 reacties op 'Net en overzichtelijk programmeren'
Gesponsorde koppelingen
tutorial:
Dit eenmaal gezegd te hebben, en het deel van variablen binnen de quotes zijn vergeten.
Gaan we variablen buiten quotes halen, omdat dit gewoon netter en overzichtelijker is.
Waarom?? Omdat het dan kleurtjes krijgt!! (en daar is iedereen dol op)
Gaan we variablen buiten quotes halen, omdat dit gewoon netter en overzichtelijker is.
Waarom?? Omdat het dan kleurtjes krijgt!! (en daar is iedereen dol op)
Ik vraag me af waarom jij een tutorial schrijft en of je het allemaal zelf wel snapt....
Tis ' en " niet die.
Zoals ik hiervoor al zei,
Dit heeft met word te maken, Ik heb het nu gewijzegd.
Ze zitten klaarblijkelijk onder dezelfde toest.
Probeer maar eens in word een " en dan hier plakken, dan word dat ook z'n schuine.
Dit heeft met word te maken, Ik heb het nu gewijzegd.
Ze zitten klaarblijkelijk onder dezelfde toest.
Probeer maar eens in word een " en dan hier plakken, dan word dat ook z'n schuine.
Edit:
Waarom ik een tut schrijf,,
Omdat het kan!!
En of ik het begrijp,, ja.
Ik weet namelijk dondersgoed dat een variable binnen dubbele quotes net zo goed werkt als erbuiten, maar zodra ze derbuiten staan, zijn ze makkelijker te herkennen.
Waarom ik een tut schrijf,,
Omdat het kan!!
En of ik het begrijp,, ja.
Ik weet namelijk dondersgoed dat een variable binnen dubbele quotes net zo goed werkt als erbuiten, maar zodra ze derbuiten staan, zijn ze makkelijker te herkennen.
Mooie TuT!
Echter hoodletters in je If ?? PHP 6 gaat dan volgens mij iig in functies warnings gooien, of dat met If zal zijn weet ik niet...
Die methode :
Dit deed ik eerst ook. Erg handig. Echter zegt zend dat je beter kan doen:
Echter hoodletters in je If ?? PHP 6 gaat dan volgens mij iig in functies warnings gooien, of dat met If zal zijn weet ik niet...
Die methode :
Dit deed ik eerst ook. Erg handig. Echter zegt zend dat je beter kan doen:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?php
if(condition) {
// hier code
} else {
// else
}
[/code]
Nu mag je natuurlijk zelf kiezen, wat jij handig en overzichtelijk vind.
Deze methode heeft als voordeel:
1. op elke } en } else bespaar je regels, dus word je script kleiner
2. Zend raad het aan, dus zullen er heel wat mensen deze methode gebruiken
nadelen
Het is soms (eigenlijk meestal als je geen goeie editor hebt) moeilijk te zien welke } bij welke { hoord.
Dus het is net wat je wilt :)
if(condition) {
// hier code
} else {
// else
}
[/code]
Nu mag je natuurlijk zelf kiezen, wat jij handig en overzichtelijk vind.
Deze methode heeft als voordeel:
1. op elke } en } else bespaar je regels, dus word je script kleiner
2. Zend raad het aan, dus zullen er heel wat mensen deze methode gebruiken
nadelen
Het is soms (eigenlijk meestal als je geen goeie editor hebt) moeilijk te zien welke } bij welke { hoord.
Dus het is net wat je wilt :)
Die hoofdletter in die if was niet de bedoeling,
Maar aangezien ik nu niet thuis zit, en hier alleen word heb, gebeurt dat zo af en toe regelmatig.
Voor de rest ken ik Zend alleen van naam, en niet van hoe het werkt en wat hun aanraden.
ik gebruik zelf net zo lief een nieuwe regel, Maar dat is voledig persoonlijke voorkeur.
Ik heb voor deze manier gekozen, omdat ik het zelf overzichtelijker vind, en daar gaat deze tut over :P
Maar aangezien ik nu niet thuis zit, en hier alleen word heb, gebeurt dat zo af en toe regelmatig.
Voor de rest ken ik Zend alleen van naam, en niet van hoe het werkt en wat hun aanraden.
ik gebruik zelf net zo lief een nieuwe regel, Maar dat is voledig persoonlijke voorkeur.
Ik heb voor deze manier gekozen, omdat ik het zelf overzichtelijker vind, en daar gaat deze tut over :P
Netjes Nico.
Ik heb ??n regel gevonden waar je de puntkomma bent vergeten. (En een w achter U => Uw). (Lekker belangrijk verder).
Echo 'U naam is '. $voornaam . $achternaam
Ik raad trouwens iedereen aan om, net als in de tutorial, de { en } recht boven elkaar te houden. Dat is v??l overzichtelijker dan zoals in de post hierboven.
Ik heb ??n regel gevonden waar je de puntkomma bent vergeten. (En een w achter U => Uw). (Lekker belangrijk verder).
Echo 'U naam is '. $voornaam . $achternaam
Ik raad trouwens iedereen aan om, net als in de tutorial, de { en } recht boven elkaar te houden. Dat is v??l overzichtelijker dan zoals in de post hierboven.
@Iltar
"Dit deed ik eerst ook. Erg handig. Echter zegt zend dat je beter kan doen"
>> Het gehele Zend Framework doet toch echt { op een nieuwe regel...
>> Deed jij ook altijd van wat ik weet.
>> En mee eens dat het onzin en verspilde ruimte is ja, en overzichtelijk genoeg!
is in een switch nog overzichtelijker. Ik mag voor complexe controle structures graag switches gebruiken, hoewel dat voor veel mensen geen common practice is....
Comments:
Als je echt gaat programmeren in php, dan is PHPDocumenter een must!
http://www.phpdoc.org/
Quotes:
in een echo zijn comma's sneller als punten! Is minimaal, maar toch...
En verder kunnen single quotes wel sneller zijn, maar het ligt er ook maar aan wat je moet outputten!
>> html bevat vaak ="" voor attributes, dus is zijn single quotes handiger!
>> SQL bevat soms '' voor params, dus zijn juist "" handiger
Ik vind deze tut niet echt veel toevoegen persoonlijk...
"Dit deed ik eerst ook. Erg handig. Echter zegt zend dat je beter kan doen"
>> Het gehele Zend Framework doet toch echt { op een nieuwe regel...
>> Deed jij ook altijd van wat ik weet.
>> En mee eens dat het onzin en verspilde ruimte is ja, en overzichtelijk genoeg!
Code (php)
is in een switch nog overzichtelijker. Ik mag voor complexe controle structures graag switches gebruiken, hoewel dat voor veel mensen geen common practice is....
Code (php)
Comments:
Als je echt gaat programmeren in php, dan is PHPDocumenter een must!
http://www.phpdoc.org/
Quotes:
in een echo zijn comma's sneller als punten! Is minimaal, maar toch...
En verder kunnen single quotes wel sneller zijn, maar het ligt er ook maar aan wat je moet outputten!
>> html bevat vaak ="" voor attributes, dus is zijn single quotes handiger!
>> SQL bevat soms '' voor params, dus zijn juist "" handiger
Ik vind deze tut niet echt veel toevoegen persoonlijk...
Allereerst, mooi initiatief! Dit is een tutorial waar veel mensen wat aan zullen hebben. Maar ik heb wel een paar opmerkingen.
Wat betreft dat buiten quotes halen van variabelen, het komt nu een beetje over dat je dat maar moet doen omdat een ander dat zegt. Een paar voorbeeldjes kunnen natuurlijk geen kwaad...
Iets dat bijvoorbeeld fout gaat:
Iets dat functioneler en overzichtelijker is:
Verder geef je de reden dat het 'veiliger' is, daar mag je van mij dan nog wel even een uitleg bij geven. Het lijkt mij namelijk niet dat dit enige invloed heeft op de veiligheid van je scripts...
Hier ontbreekt de correcte uitleg van het concatenatie teken, want dat is wat die punt is! Dit teken is niet bedoeld om een echo te openen of te sluiten of om variabelen te scheiden, maar juist om verschillende strings aan elkaar te plakken. Of die strings nu in een echo staan of in de vorm van variabelen in het script staan, doet er verder helemaal niet toe.
Tenslotte is het misschien geen gek idee om nog eens goed naar de teksten die je geschreven hebt te kijken, of wellicht te laten kijken. Je schrijfstijl laat namelijk nog wel wat te wensen over waardoor je tutorial niet lekker wegleest. En dat komt de informatie overdracht niet echt ten goede.
Wat betreft dat buiten quotes halen van variabelen, het komt nu een beetje over dat je dat maar moet doen omdat een ander dat zegt. Een paar voorbeeldjes kunnen natuurlijk geen kwaad...
Iets dat bijvoorbeeld fout gaat:
Iets dat functioneler en overzichtelijker is:
Verder geef je de reden dat het 'veiliger' is, daar mag je van mij dan nog wel even een uitleg bij geven. Het lijkt mij namelijk niet dat dit enige invloed heeft op de veiligheid van je scripts...
Quote:
echo ... openen of sluiten met een ?.?
Quote:
moet je die scheiden met een ?.?
Hier ontbreekt de correcte uitleg van het concatenatie teken, want dat is wat die punt is! Dit teken is niet bedoeld om een echo te openen of te sluiten of om variabelen te scheiden, maar juist om verschillende strings aan elkaar te plakken. Of die strings nu in een echo staan of in de vorm van variabelen in het script staan, doet er verder helemaal niet toe.
Quote:
Dat is geen functie, maar gewoon een newline character. Niets meer niets minder.Ook de \n functie ...
Quote:
Je raadt aan om dus enkele quotes te gebruiken. Doe dat dan ook consequent in je voorbeelden, met name de voorbeelden op de eerste paginas.Hieruit blijkt dus dat enkele quotes sneller zijn.
Tenslotte is het misschien geen gek idee om nog eens goed naar de teksten die je geschreven hebt te kijken, of wellicht te laten kijken. Je schrijfstijl laat namelijk nog wel wat te wensen over waardoor je tutorial niet lekker wegleest. En dat komt de informatie overdracht niet echt ten goede.
Ik vind zulk soort pagina's welk verplichte kost: http://www.evolt.org/article/PHP_coding_guidelines/18/60247/index.html
Hoewel ik niet altijd eens ben met zon guideline staan er toch handige tips in. En gebruik vooral je eigen manier waar je zelf het snelst in programmeert :)
Hoewel ik niet altijd eens ben met zon guideline staan er toch handige tips in. En gebruik vooral je eigen manier waar je zelf het snelst in programmeert :)
Code (php)
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
31
32
33
34
35
36
37
38
39
40
41
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
31
32
33
34
35
36
37
38
39
40
41
<?php
abstract class Image_Abstract{
protected $resource = null;
/**
* Create a GD image resource in every possible way.
*
* @magic
* @access public
* @param mixed $resource
* @throws Exception
*/
public function __construct($resource){
switch(true){
case (is_resource($resource) && get_resource_type($resource) == 'gd') :
$this->resource = $resource;
break;
case (is_string($resource)) :
$extension = pathinfo($resource, PATHINFO_EXTENSION);
switch($extension){
case 'gif' :
$this->resource = @imagecreatefromgif($resource);
break;
case 'jpe' :
case 'jpg' :
case 'jpeg' :
$this->resource = @imagecreatefromjpeg($resource);
break;
case 'png' :
$this->recource = @imagecreatefrompng($resource);
break;
case (($this->resource = @imagecreatefromstring($resource))) :
break;
}
case (false === $this->resource) :
default:
throw new Exception('Unabable to create Image');
}
}
?>
abstract class Image_Abstract{
protected $resource = null;
/**
* Create a GD image resource in every possible way.
*
* @magic
* @access public
* @param mixed $resource
* @throws Exception
*/
public function __construct($resource){
switch(true){
case (is_resource($resource) && get_resource_type($resource) == 'gd') :
$this->resource = $resource;
break;
case (is_string($resource)) :
$extension = pathinfo($resource, PATHINFO_EXTENSION);
switch($extension){
case 'gif' :
$this->resource = @imagecreatefromgif($resource);
break;
case 'jpe' :
case 'jpg' :
case 'jpeg' :
$this->resource = @imagecreatefromjpeg($resource);
break;
case 'png' :
$this->recource = @imagecreatefrompng($resource);
break;
case (($this->resource = @imagecreatefromstring($resource))) :
break;
}
case (false === $this->resource) :
default:
throw new Exception('Unabable to create Image');
}
}
?>
Nog een voorbeeldje... is meer een factory pattern eigenlijk...
Wel handig inderdaad, zo'n tutorial. :) Nu hopen dat het gebruikt wordt, zodat het nakijken van scripts eenvoudiger is.
Misschien nog leuk om toe te voegen hoe je SQL code in je PHP overzichtelijk uitschrijft, ik gebruik daarvoor altijd onderstaande methode:
Juist door dit soort dingen ook netjes en overzichtelijk in te voeren in je code, lijkt een query niet meer 1 lange string en is deze ook snel en eenvoudig leesbaar. Voordeel is ook dat SQL een regelnummer teruggeeft, dus dat je nooit ver hoeft te kijken naar je fout.
Misschien nog leuk om toe te voegen hoe je SQL code in je PHP overzichtelijk uitschrijft, ik gebruik daarvoor altijd onderstaande methode:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
<?php
$sql = "
SELECT
naam,
voorletters
FROM
table
WHERE
voorwaarde = 1
";
?>
$sql = "
SELECT
naam,
voorletters
FROM
table
WHERE
voorwaarde = 1
";
?>
Juist door dit soort dingen ook netjes en overzichtelijk in te voeren in je code, lijkt een query niet meer 1 lange string en is deze ook snel en eenvoudig leesbaar. Voordeel is ook dat SQL een regelnummer teruggeeft, dus dat je nooit ver hoeft te kijken naar je fout.
Quote:
de if loops
Kleine correctie: een 'if-loop' bestaat niet je bedoelt zeker een if-statement of een if/else constructie.
Quote:
in notepad
Met alle respect, kies een goede editor. Programmeren in notepad is gewoon geen doen, zeker niet als je de functionaliteiten van een goede editor leert kennen.
Ik vind het makkelijk om zo te programeren:
ik gebruik de inspring niet zo als jullie hem gebruiken
voorbeeld:
maar ik denk dat ieder het op zijn manier leert
ik zelf gebruik geen editors om een php script te maken
ik gebruik de inspring niet zo als jullie hem gebruiken
voorbeeld:
Code (php)
maar ik denk dat ieder het op zijn manier leert
ik zelf gebruik geen editors om een php script te maken
@Madhouse: als je 2500 regels code in die stijl hebt, is het dan nog steeds overzichtelijk? Ik betwijfel het...
De manier waarop je programmeert is niet enkel voor jezelf, maar ook voor anderen die je code lezen. Enige vorm van overzichtelijkheid is dan wel vereist en 'hoe compacter hoe beter' gaat dan meestal niet op.
De manier waarop je programmeert is niet enkel voor jezelf, maar ook voor anderen die je code lezen. Enige vorm van overzichtelijkheid is dan wel vereist en 'hoe compacter hoe beter' gaat dan meestal niet op.
Gebruik gewoon de Zend standaard of PEAR standaard. Er zijn niet voor niets standaarden.
@Blanche
Helaas zie je in de standaarden van PHP (Zend, PEAR) en bijvoorbeeld Java dat de manier van MaDHouSe toch echt het meest wordt gewaardeerd. Achter die standaarden liggen meestal psychologische onderzoeken en heel veel gebruikerservaringen.
Daarnaast ben je heel fout bezig als je 2500 regels code hebt. Dan heeft het niet meer met programmeerstijl qua opmaak te maken maar met (gebrek aan) logica.
@Blanche
Helaas zie je in de standaarden van PHP (Zend, PEAR) en bijvoorbeeld Java dat de manier van MaDHouSe toch echt het meest wordt gewaardeerd. Achter die standaarden liggen meestal psychologische onderzoeken en heel veel gebruikerservaringen.
Daarnaast ben je heel fout bezig als je 2500 regels code hebt. Dan heeft het niet meer met programmeerstijl qua opmaak te maken maar met (gebrek aan) logica.
Vind dit toch duidelijker, maar het is allemaal zo persoonlijk, hoeveel nut kan een tutorial erover hebben?
http://en.wikipedia.org/wiki/Indent_style
Zoals je ziet, allemaal verschillende stijlen die allemaal gebruikt worden...
Zoals je ziet, allemaal verschillende stijlen die allemaal gebruikt worden...
Quote:
Het is alleen jammer dat hoe meer standaarden er zijn, hoe minder nut ze hebben. Het begrip 'standaard' vervaagt dan immers.Gebruik gewoon de Zend standaard of PEAR standaard. Er zijn niet voor niets standaarden.
Is er trouwens ?cht een aparte Zend standaard naast de PEAR coding standaard, of zijn die hetzelfde?
Naar mijn mening is het ook niet zo belangrijk welke standaard je aan houd, al verzin je er zelf een, maar dat je er een aan houd.
Voor je zelf is het makkelijk, maar zeker als je in een project werkt, weet gewoon iedereen waar hij/zij aan toe is.
Geen idee of het er voor PHP ook is, maar bij Java kan je bijvoorbeeld met Ant instellen dat aan bepaalde regels voldaan moet worden en anders zal er geen build gemaakt kunnen worden. Ook handig om af te dwingen dat mensen commentaar plaatsen anders wordt dat nog al eens vergeten en dat zijn dingen die achteraf nooit verbeterd worden.
Voor je zelf is het makkelijk, maar zeker als je in een project werkt, weet gewoon iedereen waar hij/zij aan toe is.
Geen idee of het er voor PHP ook is, maar bij Java kan je bijvoorbeeld met Ant instellen dat aan bepaalde regels voldaan moet worden en anders zal er geen build gemaakt kunnen worden. Ook handig om af te dwingen dat mensen commentaar plaatsen anders wordt dat nog al eens vergeten en dat zijn dingen die achteraf nooit verbeterd worden.
Persoonlijk vind ik dit wel een handige sql manier (let niet op de slechte sql):
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
$query = "
SELECT vt.veld1 AS somefield,
jt.veld1 AS anotherfield,
DATE_FORMAT(vt.datum, '%W %M %Y') AS formatted_date,
MAX(jt.veld3) AS maxed
FROM velden_tabel vt
INNER JOIN data_tabel jt
ON jt.veld1 = vt.veld1
WHERE vt.id = '1'
ORDER BY vr.veld1
LIMIT 10
OFFSET 0
";
?>
$query = "
SELECT vt.veld1 AS somefield,
jt.veld1 AS anotherfield,
DATE_FORMAT(vt.datum, '%W %M %Y') AS formatted_date,
MAX(jt.veld3) AS maxed
FROM velden_tabel vt
INNER JOIN data_tabel jt
ON jt.veld1 = vt.veld1
WHERE vt.id = '1'
ORDER BY vr.veld1
LIMIT 10
OFFSET 0
";
?>
Hongaarse notatie. Google maar. Naar mijn mening is dat voor dynamicly typed talen als PHP niet erg relevant. Een float gedraagt zich binnen PHP hetzelfde als een integer of een double. Een string kan je ook optellen. PHP zet de waarden zelf om naar dat wat er op dat moment nodig is. De Hongaarse notatie dan gebruiken en jezelf eraan houden zorgt er dan alleen maar voor dat je deze flexibiliteit niet langer kan gebruiken. Als je de flexibiliteit niet wil, waarom dan PHP en niet Java of C++?
Daarnaast moet je het leren lezen. Voor beginners is het onduidelijk, en veel voorvoegsels zijn ambigu, en het leest niet vloeiend. Je kan zonder al te veel moeite in PHP prima scripts schrijven die bijna lezen als correct engels.
En als laatste argument waarom ik vind dat je de Hongaarse notatie binnen PHP niet moet hanteren: Je variabelen hebben als het goed is het type al in de naam zitten. Een naam is niet een integer of een resource. Een naam is duidelijk een string of een object. En dat onderscheidt hoef je ook niet te noteren, daar moet je gewoon consistent mee zijn in je script. Als $naam op regel 6 een object is dat de naam representeert, dan moet hij op regel 45 niet plots een string zijn. Naar mijn idee doe je dan iets vreemds.
Daarnaast moet je het leren lezen. Voor beginners is het onduidelijk, en veel voorvoegsels zijn ambigu, en het leest niet vloeiend. Je kan zonder al te veel moeite in PHP prima scripts schrijven die bijna lezen als correct engels.
En als laatste argument waarom ik vind dat je de Hongaarse notatie binnen PHP niet moet hanteren: Je variabelen hebben als het goed is het type al in de naam zitten. Een naam is niet een integer of een resource. Een naam is duidelijk een string of een object. En dat onderscheidt hoef je ook niet te noteren, daar moet je gewoon consistent mee zijn in je script. Als $naam op regel 6 een object is dat de naam representeert, dan moet hij op regel 45 niet plots een string zijn. Naar mijn idee doe je dan iets vreemds.
@Jelmer
Ik ben juist wel voor de hongaarse notatie. Zeker wanneer ergens veel variabelen worden gebruikt is het snel zichtbaar wat voor soort de input is of moet zijn.
Bijkomend voordeel is dat je (jij noemt het al eigenlijk) strings wel kan optellen, maar dat slaat nergens op en hoort niet. Door de hongaarse notatie te gebruiken voor een variabele zie je ook meteen dat er iets niet is zoals het hoort wanneer je $iTotaal = $iBegin + $sEind intypt.
Verder heb je qua lezen wel gelijk, soms leest het wat raar, maar ook dat went snel. Wat ik ook handig vind is omdat mijn editor variabelen namen ook automatisch aanvult en ik wil rekenen hoef ik maar $i te typen en ik krijg alle variabelen die een integer zijn te zien.
Ik ben juist wel voor de hongaarse notatie. Zeker wanneer ergens veel variabelen worden gebruikt is het snel zichtbaar wat voor soort de input is of moet zijn.
Bijkomend voordeel is dat je (jij noemt het al eigenlijk) strings wel kan optellen, maar dat slaat nergens op en hoort niet. Door de hongaarse notatie te gebruiken voor een variabele zie je ook meteen dat er iets niet is zoals het hoort wanneer je $iTotaal = $iBegin + $sEind intypt.
Verder heb je qua lezen wel gelijk, soms leest het wat raar, maar ook dat went snel. Wat ik ook handig vind is omdat mijn editor variabelen namen ook automatisch aanvult en ik wil rekenen hoef ik maar $i te typen en ik krijg alle variabelen die een integer zijn te zien.
$sEind is op zichzelf al een slechte variabele-naam. Eind van wat? $naam++ slaat ook nergens op, dan zou je eerder iets in de trant van $naam_count verwachten, en dan is het niet meer dan logisch dat dat het een integer is.
Mijn idee is dat een variabelenaam de inhoud moet dekken, moet beschrijven wat erin zit (al dan niet binnen de context. Datum::$begin en Datum::$eind is logisch, maar Naam::$begin is te open, begin-wat?) De Hongaarse notatie is de easy way out die je niet echt helpt op de lange termijn. Een al dan niet iets langere variabele-naam die de inhoud dekt is volgens mij voor de lange termijn, wanneer je na een paar jaar weer terugkijkt op de code of wanneer je je code deelt met anderen veel sneller te begrijpen.
Mijn idee is dat een variabelenaam de inhoud moet dekken, moet beschrijven wat erin zit (al dan niet binnen de context. Datum::$begin en Datum::$eind is logisch, maar Naam::$begin is te open, begin-wat?) De Hongaarse notatie is de easy way out die je niet echt helpt op de lange termijn. Een al dan niet iets langere variabele-naam die de inhoud dekt is volgens mij voor de lange termijn, wanneer je na een paar jaar weer terugkijkt op de code of wanneer je je code deelt met anderen veel sneller te begrijpen.
@Jelmer
De notatie Datum::$begin is inderdaad duidelijk, maar is wel een notatie die je meer in OOP gebruikt. Het voorbeeld wat ik gaf was meer bedoeld om te laten zien dat het ook echt wel voordelen heeft.
Ik ben met je eens dat je meteen de lading van de inhoud in een variabele moet dekken, daar was het voorbeeld ook niet voor bedoeld. Het ligt er ook maar net aan wat je gewend bent. In OOP gebruik je ook geen hongaarse notatie, ben ik met je eens, maar OOP gaat bij mij nog niet zo vanzelf dat ik ook vaak procedureel nog gebruik. En dan vind ik het wel handig.Maargoed, smaken verschillen en wil er ook geen discussie over gaan voeren.
De notatie Datum::$begin is inderdaad duidelijk, maar is wel een notatie die je meer in OOP gebruikt. Het voorbeeld wat ik gaf was meer bedoeld om te laten zien dat het ook echt wel voordelen heeft.
Ik ben met je eens dat je meteen de lading van de inhoud in een variabele moet dekken, daar was het voorbeeld ook niet voor bedoeld. Het ligt er ook maar net aan wat je gewend bent. In OOP gebruik je ook geen hongaarse notatie, ben ik met je eens, maar OOP gaat bij mij nog niet zo vanzelf dat ik ook vaak procedureel nog gebruik. En dan vind ik het wel handig.Maargoed, smaken verschillen en wil er ook geen discussie over gaan voeren.
Datum::$begin was een voorbeeld dat iets simpels als $begin wel beschrijvend kan zijn, maar dat is dankzij z'n context (als property van Datum) Datzelfde geldt voor de plaats van de variabele binnen de code. $i middenin je code is verwarrend, maar $i bij een for-lus gebruiken voor een oplopend of aflopend nummertje is heel normaal. Maar je moet jezelf dan wel ervan weerhouden de $i buiten een for-lus te gebruiken.
Jouw voorbeeld was een goed voorbeeld wat betreft het nut van de Hongaarse notatie, maar een slecht voorbeeld omdat de variabelenaam $eind simpelweg niet goed gekozen is, en het probleem dat dat oplevert beter op te lossen is door $eind te veranderen in een naam die zijn lading dekt in plaats van een 'i' in de naam op te nemen.
Jouw voorbeeld was een goed voorbeeld wat betreft het nut van de Hongaarse notatie, maar een slecht voorbeeld omdat de variabelenaam $eind simpelweg niet goed gekozen is, en het probleem dat dat oplevert beter op te lossen is door $eind te veranderen in een naam die zijn lading dekt in plaats van een 'i' in de naam op te nemen.
Ik gebruikte eerst ook de hongaarse notatie... Werkt eigenlijk niet makkelijk in php. In Java/C++ idd wel, maar daar gebruik ik het ook niet.
Ik volg een beetje de zend methode:
$userData = new User($userId);
kijk hier bv
$row = mysql_fetch_object();
$row = mysql_fetch_assoc();
Je haalt hetzelfde op, alleen dan in feite een andere methode.
Makkelijste manier, is dan ipv de strings aan te pakken, gewoon een manier verzinnen om altijd de juiste data te pakken te krijgen:
Een array object (of recursive zoals die van mij) die gepakt kan worden op:
$arr['key']
en
$arr->key
stel dat je een mixed input kan hebben van array of object...
$aooVar (aoo = array or object)
dan word het alweer lastig...
Als je duidelijk programmeert heb je die hele hongaarse methode niet nodig:
Dat is dus de handigheid, kortom, hongaarse methode is te veel denk werk en kan in sommige gevallen niet.
Ik volg een beetje de zend methode:
$userData = new User($userId);
kijk hier bv
$row = mysql_fetch_object();
$row = mysql_fetch_assoc();
Je haalt hetzelfde op, alleen dan in feite een andere methode.
Makkelijste manier, is dan ipv de strings aan te pakken, gewoon een manier verzinnen om altijd de juiste data te pakken te krijgen:
Een array object (of recursive zoals die van mij) die gepakt kan worden op:
$arr['key']
en
$arr->key
stel dat je een mixed input kan hebben van array of object...
$aooVar (aoo = array or object)
dan word het alweer lastig...
Als je duidelijk programmeert heb je die hele hongaarse methode niet nodig:
Code (php)
Dat is dus de handigheid, kortom, hongaarse methode is te veel denk werk en kan in sommige gevallen niet.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
Inhoudsopgave
Labels
- Geen tags toegevoegd.
PHP hulp
0 seconden vanaf nu