[PHP] (te)veel brakke code

[Verwijderd]

RwD schreef op 06 juli 2004 @ 16:01:
[...]
Parsen/scannen, je wist wat ik bedoel. Ik wil nogal snel parsen zeggen terwijl ik vrijwel altijd scannen bedoel (ik werk momenteel met Omnimark, mocht je dat wat zeggen)

Punt is dat je zelf al aangeeft dat een string met dubbele quotes langzamer is. Dat ze ook even snel kunnen zijn doet er niet toe, alle toepassingen meegenomen is een dubbelquote gemiddeld langzamer dan een single quote string, en dus langzamer...

Of niet dan? Anders is een fiat net zo snel als een ferrari, tenzij de fiat een ferrari Enzo is, want een Ferrari valt onder het Fiat concern. <-- die laatste zin hoef je niet letterlijk te nemen, de vergelijking viel tijdens het typen buiten de context.
Ik bedoelde dat twee auto's dan ook even snel zijn, totdat je in eentje een dik persoon met veel dollars zet, die niet in de andere past. In principe ga je dan die persoon altijd in die ene auto proppen, en als iemand anders mee wil kan ie beter in de andere auto gaan zitten, die is meestal sneller...

Absoluut gezien heb je misschien gelijk, maar relatief zijn beide functies even snel. Het is toch logisch dat een functie die meer moet berekenen trager is? De indruk werd alleen gewekt dat het gebruik van dubbele quotes slecht is als je een string gebruikt zonder escape tekens en zonder variabelen. en dát is nou net niet waar.

[Verwijderd]

Janoz schreef op 06 juli 2004 @ 15:59:

PHP:

if (!get_magic_quotes_gpc()) {
   $lastname = addslashes($_POST['lastname']);
} else {
   $lastname = $_POST['lastname'];
}

Dit is de manier waarop het imho in alle te downloade server onafhankelijke voorbeelden zou moeten voorkomen.

Voor beginners is zoiets wel handig, maar ik ben het er niet mee eens. Veel variabelen worden nooit in een query of shell commando gestopt, dus zit je nodeloze slashes toe te voegen.

Ik zie liever dat tutorials aangeven dat je gpc_magic_quotes het best uit kunt zetten en dat je verdomd goed moet begrijpen hoe alles in elkaar zit. Leuk dat PHP oorspronkelijk bedoeld was voor eenvoudige zaken, maar als je nu nog PHP moet leren dan kun je dat het best meteen goed doen. En iedereen die PHP gebruikt zal moeten begrijpen wanneer addslashes nodig is en wanneer niet.

Gevorderden kunnen trouwens zelf wel een database class schrijven die een soort prepared statements kent, en een manier om automatisch tekens uit strings te escapen.

De manier van Jorgen begrijp ik trouwens niet helemaal. Het is niet handig om bepaalde tekens in een string te vervangen door HTML entities.

[.oisyn]

megamuch schreef op 06 juli 2004 @ 15:34:
Mag ik dan ook even de andere kant op pissen.

doe het dan niet tegen de wind in, dan word je nat

Like who the f*ck cares??

Misschien de gevorderde programmeur die naast PHP nog wel wat andere talen kent?

PHP is een simpele scripting taal met een berg aan functies die je in andere talen zelf zou moeten schrijven.

Right, in .Net en Java heb je tenslotte ook geen uitgebreide standaard library, toch?

PHP is snel.

* kuch *

PHP is eenvoudig om te leren.

Dat is geen argument

PHP heeft plenty of built-in functies die erg handig zijn.

Dat hebben andere talen dus ook

En buiten dat, er is een gigantische support voor de taal. Hulp nodig? Check 1 van de 1001 sites over php en je kan je antwoord vaak genoeg wel vinden.

Ja da's misschien leuk voor de beginner, maar de gevorderde heeft ten eerste die hulp niet echt nodig, en ten tweede zijn de voorbeelden die over php op het internet te vinden zijn zo ranzig als mijn kont als ik zojuist gescheten heb

Waar mensen hier vooral aan voorbij gaan is het feit dat ze php willen gebruiken als volwaardige programmeer omgeving. Iets wat 90% van de php scripters niet nodig hebben, laat staan snappen.

Non-argument. Omdat dat voor een groot deel toevallig ook de beginnende programmeurs zijn, wil nog niet zeggen dat dat maar als een excuus gebruikt kan worden om het ranzig te laten. Nergens voor nodig, je kunt best een goede taal opzetten die ook makkelijk te leren is en een handige feature-set heeft. Sommige dingen zijn in PHP gewoon ranzig slecht uitgewerkt omdat daar niet goed over nagedacht is. Als die fouten verbeterd zouden worden dan blijft de taal nog net zo toegankelijk voor iedereen, het wordt alleen wat fijner voor de mensen die wel het voordeel kennen van de andere programmeertalen

ik heb geen idee wat een object is
geen flauw idee wat ik met inheritance moet
public of private? yeah whatever

OO in PHP is sowieso een no-go, dus wat je nu zegt is niet echt relevant. En omdat jij niet weet wat dat allemaal is, moet php maar zo ranzig blijven als het is

En toch kan ik met php aardige scripjes schrijven. Simpele websitejes bouwen met zoekmogelijkheden etc. Prima. Class downloaden en gebruiken in m'n scripts wil ook nog wel lukken.

En wat is nou het punt dat je hiermee wilt maken?

Begrijp me niet verkeerd hoor, ik vind PHP een prima taal voor de klein tot middelmatige projecten, alleen soms zijn er van die dingen waarvan je denkt: ja, had dat nou net even anders gedaan, dan had het veel fijner gewerkt. Het is niet zo dat gezegd wordt dat de hele taal omgegooid moet worden, het zijn gewoon die kleine dingetjes die tot veel irritatie kunnen leiden

Als je al die fancy dingen nodig hebt, pak dan .NET / java / en laat php links liggen.

Waarom? Als je een fiat sneller kan maken (om maar even dat voorbeeld aan te houden ) door 1 boutje aan te draaien, waarom zou je die dan links laten liggen en een ferrari kopen, met alle nadelen van dien (duurder, meer risico, etc.)


.edit:
Wat je dus eigenlijk zegt is dat jij PHP niet ranzig vindt omdat jij niet zo heel veel verstand hebt van programmeren en architectuur, en je dus eigenlijk totaal niet weet waarover je praat, maar toch vind je de dingen die gezegd worden onzin en je vind dat die mensen dan maar een andere programmeertaal moeten gebruiken

[ Voor 6% gewijzigd door .oisyn op 06-07-2004 16:57 ]

[Janoz]

Verwijderd schreef op 06 juli 2004 @ 16:20:
[...]

Voor beginners is zoiets wel handig, maar ik ben het er niet mee eens. Veel variabelen worden nooit in een query of shell commando gestopt, dus zit je nodeloze slashes toe te voegen.

In dat geval wordt het dus:

PHP:

if (get_magic_quotes_gpc()) {
   $lastname = stripslashes($_POST['lastname']);
} else {
   $lastname = $_POST['lastname'];
}

Ik zie liever dat tutorials aangeven dat je gpc_magic_quotes het best uit kunt zetten en dat je verdomd goed moet begrijpen hoe alles in elkaar zit. Leuk dat PHP oorspronkelijk bedoeld was voor eenvoudige zaken, maar als je nu nog PHP moet leren dan kun je dat het best meteen goed doen. En iedereen die PHP gebruikt zal moeten begrijpen wanneer addslashes nodig is en wanneer niet.

Helemaal mee eens. Veel mensen snappen er geen drol van. Ze gebruiken vervolgens speciale tekens en gaan vervolgens de addslashesh methode hierop aanroepen.

$var = addslashes("tekst met " erin");

Die hebben er weinig van begrepen, en ik kan het ze niet kwalijk nemen.

Gevorderden kunnen trouwens zelf wel een database class schrijven die een soort prepared statements kent, en een manier om automatisch tekens uit strings te escapen.

De manier van Jorgen begrijp ik trouwens niet helemaal. Het is niet handig om bepaalde tekens in een string te vervangen door HTML entities.

idd. Het aanpassen van de entities doe ik zelf altijd pas op het moment van afdrukken.

PHP:

<? ?>
<html>
 <head>
  <title><?=html_entity_encode($title)?></title>
  </head>
 <body>
  <?=html_entity_encode($content)?>
 </body>
</html>
  
<? ?>

[pjonk]

Verwijderd schreef op 06 juli 2004 @ 16:20:
Voor beginners is zoiets wel handig, maar ik ben het er niet mee eens. Veel variabelen worden nooit in een query of shell commando gestopt, dus zit je nodeloze slashes toe te voegen.

Mee eens. Net als register_globals, wat in het begin ook heel handig leek, maar bij nader inzien uitnodigde voor gevaarlijke en onduidelijke code.

Ik zie liever dat tutorials aangeven dat je gpc_magic_quotes het best uit kunt zetten en dat je verdomd goed moet begrijpen hoe alles in elkaar zit. Leuk dat PHP oorspronkelijk bedoeld was voor eenvoudige zaken, maar als je nu nog PHP moet leren dan kun je dat het best meteen goed doen. En iedereen die PHP gebruikt zal moeten begrijpen wanneer addslashes nodig is en wanneer niet.

Yep gpc_magic_quotes was in het leven geroepen, omdat er legio programmeurs waarbij het woord escapen niet in hun vocabulair voorkwam.
De meeste hosters hebben deze optie nu gelukkig standaard uitstaan dus zien de programmeurs vanzelf wel de gevolgen

[Verwijderd]

Verwijderd schreef op 06 juli 2004 @ 16:20:
[...]

... knip...

De manier van Jorgen begrijp ik trouwens niet helemaal. Het is niet handig om bepaalde tekens in een string te vervangen door HTML entities.

Ik ben het eens met je verhaal dat eenieder die met PHP begint, goed moet weten waar hij/zij mee bezig is. Maar het virus der luiheid krijgt grip op iedereen.
Vooral programmeurs schijnen nogal vaak lui te zijn.

Waarom ik daar de quote vervang voor een HTML entitie snap ik ook niet. Zoals ik zei: uit de oude doos...
Nou, 't probleem is in ieder geval eenvoudig op te lossen, gewoon entitie vervangen voor \\\".

[Olaf van der Spek]

RwD schreef op 06 juli 2004 @ 16:01:
Punt is dat je zelf al aangeeft dat een string met dubbele quotes langzamer is. Dat ze ook even snel kunnen zijn doet er niet toe, alle toepassingen meegenomen is een dubbelquote gemiddeld langzamer dan een single quote string, en dus langzamer...

Dus?
Als dat verschil inderdaad relevant is, gebruik je een optimizer die geparste 'intermediate code' bijhoudt waarin het verschil tussen enkele en dubbele aanhalingstekens niet meer bestaat.

[Olaf van der Spek]

Verwijderd schreef op 06 juli 2004 @ 16:03:
Uit de oude doos:

Dat is niet equivalent aan de magic quotes functie.

[.oisyn]

RwD schreef op 06 juli 2004 @ 16:01:
Punt is dat je zelf al aangeeft dat een string met dubbele quotes langzamer is.

Dat zeg ik helemaal niet, lees even goed.

Dat ze ook even snel kunnen zijn doet er niet toe, alle toepassingen meegenomen is een dubbelquote gemiddeld langzamer dan een single quote string, en dus langzamer...

Ja en single quotes zijn langzamer als je veel ' tekens in je string wilt hebben
Premature optimisations are the root of all evil, het gebruiken van ' omdat je denkt dat " een stuk langzamer is is gewoon grote onzin. Het scheelt alleen bij gebruik van $, en zelfs dan is de tijdswinst nog minimaal. Gebruik ' dus omdat je veel $ of " wilt gebruiken, of weet ik veel wat voor andere redenen je erbij kunt bedenken, maar het gebruiken omdat het "sneller" is, is gewoon dikke onzin.

[Verwijderd]

OlafvdSpek schreef op 06 juli 2004 @ 16:43:
[...]
Dat is niet equivalent aan de magic quotes functie.

Okey, wou net mijn laatste post updaten, maar de replies schieten uit de grond...

Ik heb die functie even aangepast zodat het wel een equivalent is...

[ Voor 51% gewijzigd door Verwijderd op 06-07-2004 16:46 ]

[.oisyn]

Janoz schreef op 06 juli 2004 @ 15:59:
[...]

PHP:

if (!get_magic_quotes_gpc()) {
   $lastname = addslashes($_POST['lastname']);
} else {
   $lastname = $_POST['lastname'];
}

Dit is de manier waarop het imho in alle te downloade server onafhankelijke voorbeelden zou moeten voorkomen.

Mja, ik vind dat hele magic_quotes_* gedoe enorm ranzig. Het is natuurlijk ten eerste al fout om ervan uit te gaan van een bepaalde setting, dan valt je script meteen bij een herconfig van de server als de setting toevallig wijzigt. That said, waarom zou er dan überhaupt nog een setting zijn die zoiets regelt? En waarom? Alleen maar omdat je iets in een database wil hebben, of als parameter mee wil geven aan een shell commando? Ik heb meestal bovenin de standaard include die ik altijd include gewoon een stukje code staan dat kijkt naar de huidige setting, en als het aan staat dan gaat ie gewoon fijn de quotes verwijderen bij alle $_GET, etc. variabelen. Ook al moet ik ze later weer toevoegen als ik ze in een database wil stoppen, jammer dan. Mijn script werkt tenminste altijd, ongeacht de huidige instelling van magic_quotes_gpc (en runtime zet ik altijd in het script uit). Daarnaast zet ik het natuurlijk wel in een htaccess uit, zodat het zo efficient mogelijk maakt, maar het breekt natuurlijk niet zodra er een setting wijzigt of een htaccess zoek raakt oid

[Olaf van der Spek]

Verwijderd schreef op 06 juli 2004 @ 16:44:
[...]
Okey, wou net mijn laatste post updaten, maar de replies schieten uit de grond...

Ik heb die functie even aangepast zodat het wel een equivalent is...

Nu staat er $v = addslashes(addslashes($v)).

[Verwijderd]

.oisyn schreef op 06 juli 2004 @ 16:51:
[...]


Mja, ik vind dat hele magic_quotes_* gedoe enorm ranzig. Het is natuurlijk ten eerste al fout om ervan uit te gaan van een bepaalde setting, dan valt je script meteen bij een herconfig van de server als de setting toevallig wijzigt. That said, waarom zou er dan überhaupt nog een setting zijn die zoiets regelt? En waarom? Alleen maar omdat je iets in een database wil hebben, of als parameter mee wil geven aan een shell commando? Ik heb meestal bovenin de standaard include die ik altijd include gewoon een stukje code staan dat kijkt naar de huidige setting, en als het aan staat dan gaat ie gewoon fijn de quotes verwijderen bij alle $_GET, etc. variabelen. Ook al moet ik ze later weer toevoegen als ik ze in een database wil stoppen, jammer dan. Mijn script werkt tenminste altijd, ongeacht de huidige instelling van magic_quotes_gpc (en runtime zet ik altijd in het script uit). Daarnaast zet ik het natuurlijk wel in een htaccess uit, zodat het zo efficient mogelijk maakt, maar het breekt natuurlijk niet zodra er een setting wijzigt of een htaccess zoek raakt oid

Je bedoelt zoiets?

PHP:

<?
/** 
*  Apply magic quotes 
* 
*  @access public 
*  @param  array|string  The input variable 
*  @return void 
*  @author Jorgen Horstink 
*/ 
function remove_magic_quotes(&$arr) 
{ 
  if (ini_get('magic_quotes_gpc')) { 
    if (is_array($arr)) { 
      $c = sizeOf($arr); 
      $a = array_keys($arr); 
      for ($i = 0; $i < $c; $i++) { 
        if (is_array($arr[$a[$i]])) { 
          remove_magic_quotes($arr[$a[$i]]); 
        } else { 
          $arr[$a[$i]] = stripslashes($arr[$a[$i]]); 
        } 
      } 
    } elseif (is_string($arr)) { 
      $arr = stripslashes($arr); 
    } 
  } 
}

Ik vind wel dat .oisyn gelijk heeft. Dat hele quotes gebeuren zou gewoon altijd en overal uit moeten staan. Wat zou in vredes naam een reden kunnen zijn om alle quotes te escapen?

OlafvdSpek schreef op 06 juli 2004 @ 16:52:
[...]

Nu staat er $v = addslashes(addslashes($v)).

Ow? Hij doet alleen addslashes als PHP zelf niet automatisch quotes toevoegd...

code:

  // Dit stuk heeft niets met de functie in deze reply te maken, maar
  // met de eerder genoemde apply_magic_quotes
  if (!ini_get('magic_quotes_gpc')) {

Of ben ik nou aan het malen? 'k zit ook al weer veel te lang achter de computer...

[ Voor 16% gewijzigd door Verwijderd op 06-07-2004 17:34 ]

[.oisyn]

Verwijderd schreef op 06 juli 2004 @ 16:55:
Je bedoelt zoiets?

Nou nee meer zoiets

PHP:

function stripslashes_helper (&$v, $k)
{
    if (is_array ($v))
        array_walk ($v, "stripslashes_helper");
    else
        $v = stripslashes ($v);
}

if (get_magic_quotes_gpc ())
{
    if (isset ($_GET))
        array_walk ($_GET, "stripslashes_helper");
    
    if (isset ($_POST))
        array_walk ($_POST, "stripslashes_helper");
    
    if (isset ($_COOKIE))
        array_walk ($_COOKIE, "stripslashes_helper");
    
    if (isset ($_REQUEST))
        array_walk ($_REQUEST, "stripslashes_helper");
}

set_magic_quotes_runtime (0);

[ Voor 6% gewijzigd door .oisyn op 06-07-2004 16:59 ]

[Verwijderd]

array_walk is gewoon een rare functie...

Valt dit ook onder ranzigheid? Een string opgeven als callback functie?

[Erkens]

Verwijderd schreef op 06 juli 2004 @ 17:02:
array_walk is gewoon een rare functie...

niks raars aan, gewoon een handige functie, hoef je zelf het wiel niet uit te vinden

Valt dit ook onder ranzigheid? Een string opgeven als callback functie?

ehm, dat is gewoon de manier waarop je een callback functie doorgeeft in php, in een taal x zal dat op een andere manier zijn, taaleigen dus, niks ranzigs.
Hoewel je het altijd ranzig kan maken door die callback functie via een $_GET te verkrijgen maar iemand met hersens doet dat niet

[.oisyn]

Verwijderd schreef op 06 juli 2004 @ 17:02:
array_walk is gewoon een rare functie...

Argumentatie?

Valt dit ook onder ranzigheid? Een string opgeven als callback functie?

Zie Erkens. Het is nou eenmaal php's manier van function pointers, niets mis mee

[Verwijderd]

Okey, overtuigd... Whow, ging dat even snel

[.oisyn]

Waarom add/stripslash jij 2x

[Verwijderd]

Wederom wil ik tegen de muur aanlopen

/me gaat buiten spelen en komt morgen wel weer terug

[ Voor 97% gewijzigd door Verwijderd op 06-07-2004 17:37 ]

[Olaf van der Spek]

Erkens schreef op 06 juli 2004 @ 17:12:
niks raars aan, gewoon een handige functie, hoef je zelf het wiel niet uit te vinden

Maar waarom tussen quotes?

[Olaf van der Spek]

Verwijderd schreef op 06 juli 2004 @ 16:55:
Ow? Hij doet alleen addslashes als PHP zelf niet automatisch quotes toevoegd...

$arr[$a[$i]] = addslashes($arr[$a[$i]]);
$arr[$a[$i]] = addslashes($arr[$a[$i]]);

[Erkens]

OlafvdSpek schreef op 06 juli 2004 @ 18:18:
[...]

Maar waarom tussen quotes?

lees eens verder

Erkens schreef op 06 juli 2004 @ 17:12:
ehm, dat is gewoon de manier waarop je een callback functie doorgeeft in php, in een taal x zal dat op een andere manier zijn, taaleigen dus, niks ranzigs.

[Olaf van der Spek]

Erkens schreef op 06 juli 2004 @ 18:24:
[...]

lees eens verder

[...]

Maar dat vind ik dus een ranzig 'taaleigen' iets.
Dat het zo moet snap ik wel, de vraag is meer waarom het zo moet.

[ Voor 22% gewijzigd door Olaf van der Spek op 06-07-2004 18:28 ]

[Verwijderd]

Wat jezelf ook kan helpen is het verzinnen van programmeer-richtlijnen. Ik heb mezelf een keer overgehaald er een te verzinnen:
http://rbdata.nl/area51/Programmeer%20richtlijnen.pdf

Toch is dit bestand al niet meer relevant, variabelen zien er nu zo uit:

PHP:

$Pa_KeyValues
$s_Assign

en functies zien er nu zo uit:

PHP:

_get_AssignKeys()
_set_Var()
initialise_Object()

Programmeer richtlijnen zijn niet alleen makkelijk voor jezelf, je hoeft niet elke keer terug te kijken hoe het ook alweer moest, maar het helpt je om constant te programmeren.

Ook als je in team-verband gaat werken en iedereen heeft dezelfde regeltjes om aan te houden werkt het een stuk fijner.

PS. Ik hou dus van perfectionistisch object georiënteerd programmeren (POOP)

[PrisonerOfPain]

PEAR heeft daar ook guidlines voor opgesteld, maar die vind ik (erg) onzinig. Ze gingen (de laatste keer dat ik keek) niet in op de naamgeving van variabelen/functies maar ze hadden het wel over de meest onzinnige dingen over de manier hoe je een if statement op moest schrijven, en dat moest dan met een spatie na het openings haakje en voor het sluithaakje. Over onzinnige dingen gesproken. Ik snap dat er enige consistentie moet zijn maar bepalen waar een spatie moet zijn of niet vind ik _erg_ onzinnig.

[Erkens]

OlafvdSpek schreef op 06 juli 2004 @ 18:26:
[...]

Maar dat vind ik dus een ranzig 'taaleigen' iets.
Dat het zo moet snap ik wel, de vraag is meer waarom het zo moet.

waarom niet? is niks mis mee imo
zo heeft elke taal wel zijn eigen ranzige 'taaleigen' dingen. (voor zover je dit ranzig kan noemen)

[ Voor 10% gewijzigd door Erkens op 06-07-2004 19:19 ]

[PrisonerOfPain]

OlafvdSpek schreef op 06 juli 2004 @ 18:26:
[...]

Maar dat vind ik dus een ranzig 'taaleigen' iets.
Dat het zo moet snap ik wel, de vraag is meer waarom het zo moet.

Het is onorthodox maar dat maakt het nog niet ranzig.

[Verwijderd]

PrisonerOfPain schreef op 06 juli 2004 @ 19:16:
PEAR heeft daar ook guidlines voor opgesteld, maar die vind ik (erg) onzinig. ... if statement op moest schrijven, en dat moest dan met een spatie na het openings haakje en voor het sluithaakje.

Het is dan misschien erg overdreven om na het haakje in de if constructie een spatie te plaatsen, toch is het wel leesbaarder. Zelf doe ik het ook, bekijk het volgende voorbeeld eens en zeg dan welke je leesbaarder vindt.

PHP:

if( isset( $Pa_If[$i_X]['Else']['BeginLine'] ) )

of

PHP:

if(isset($Pa_If[$i_X]['Else']['BeginLine']))

Ik vind het eerste leesbaarder, alleen bij array constructies zoals hierboven beschreven vind het minder leesbaar om daar na de accolades ook een spatie te gebruiken:

PHP:

$Pa_If[$i_X]['Else']['BeginLine']

of

PHP:

$Pa_If[ $i_X ][ 'Else' ][ 'BeginLine' ]

Dus mijn mening is dat je zelf programmeer richtlijnen schrijft die je lekker vind om te gebruiken of die van iemand anders gebruikt die jij goed vind. Het enige wat je dan moet doen is om die aan te houden, en dat is juist moeilijker dan ze schijven.

[ Voor 20% gewijzigd door Verwijderd op 06-07-2004 19:28 ]

[PrisonerOfPain]

Verwijderd schreef op 06 juli 2004 @ 19:27:
Het is dan misschien erg overdreven om na het haakje in de if constructie een spatie te plaatsen, toch is het wel leesbaarder. Zelf doe ik het ook, bekijk het volgende voorbeeld eens en zeg dan welke je leesbaarder vindt.

Ik gebruik zelf altijd

PHP:

if (isSet ($_GET['iets']))
{
//doe gemene dingen
}

Ik ben dat gewend en vind het fijn lezen, maar nuttiger is IMHO om op te schrijven dat je (bijvoorbeeld) alle functie en variabele namen pascal case wilt hebben, de stack voor de needle moet komen en classes camel case gaan, dan heb je tenminste de grote lijnen van consistentie. Om dat over die spaties te gaan lopen mekkeren vind ik (nogmaals) onzinnig, ik bepaal zelf wat ik fijn vind lezen mocht een ander het anders fijn vinden is een code beautifier een mooie uitkomst.

Dus mijn mening is dat je zelf programmeer richtlijnen schrijft die je lekker vind om te gebruiken of die van iemand anders gebruikt die jij goed vind. Het enige wat je dan moet doen is om die aan te houden, en dat is juist moeilijker dan ze schijven.

Inderdaad, maar als het eenmaal gewenning is merk je het niet meer en ziet alles er redelijk consistent uit.

[alienfruit]

Aaah, met Ruben kan ik praten Ik zet zelf ook spaties voor en na een ( ) { } etc. Leest inderdaad fijner.

[PrisonerOfPain]

alienfruit schreef op 06 juli 2004 @ 19:52:
Aaah, met Ruben kan ik praten Ik zet zelf ook spaties voor en na een ( ) { } etc. Leest inderdaad fijner.

http://www.tote-taste.de/X-Project/beautify/

nou leest alles ineens fijn ;-)

[djluc]

Toch wil ik echt even opmerken dat we nu weer over minimale verschillen praten. Deze wegen niet op tegen een degelijk applicatie ontwerp e.d. Maar dat is in het algemeen imo sowieso al veel belangrijker. Om zaken als modulariteit e.d. goed voor elkaar te krijgen is veel meer kennis nodig dan zaken als slashes en spaties tussen haakjes. Over een jaar kan je code met of zonder spaties beter lezen dan code die gewoon niet structureel, in de zin van applicatie ontwerp, is opgebouwd.

[alienfruit]

Ja, maar Applicatieontwerp is wat anders dan de "vormgeving" van de broncode
Ach, blijft altijd lastig dat "software engineering"

[PrisonerOfPain]

djluc schreef op 06 juli 2004 @ 20:03:
Toch wil ik echt even opmerken dat we nu weer over minimale verschillen praten. Deze wegen niet op tegen een degelijk applicatie ontwerp e.d. Maar dat is in het algemeen imo sowieso al veel belangrijker. Om zaken als modulariteit e.d. goed voor elkaar te krijgen is veel meer kennis nodig dan zaken als slashes en spaties tussen haakjes.

Bedankt voor deze post , je hebt me eens aan het denken gezet, want ik zocht al een tijdje een manier om modules/plugins netjes te verzorgen. Het resultaat is een class Install die verdacht veel weg heeft van een Observer pattern.
Iedere module krijgt een register.php welke (duh) alle modules tegen de Install class registreert (de actie om uit te voeren, de bestandsnaam, functie [en class] worden doorgegeven). Het install script doorloopt daarna alle directories opzoek naar een register.php en laat die zijn componenten toevoegen.
Daarna is het relatief simpel om een actie te laten gebeuren, je doorloopt de interne array en include het juiste bestan, roept functies/methode aan die bij de geregistreerde actie hoord.

[Apache]

.oisyn schreef op 06 juli 2004 @ 16:39:
[...]

Ja da's misschien leuk voor de beginner, maar de gevorderde heeft ten eerste die hulp niet echt nodig, en ten tweede zijn de voorbeelden die over php op het internet te vinden zijn zo ranzig als mijn kont als ik zojuist gescheten heb


[...]

Imo gaat het topic ook hierover, t'is zeker niet de taal op zich die zo ranzig is, goed het is niet perfect, dat weten we allemaal maar wie/wat is dat wel.

Het zijn de beginners die hun "wauw ik heb net wat geprogrammeerd en het werkt en het is volgens mij fantastisch dus ik ga het releasen zodat anderen het niet meer moeten doen"-code online gooien welke ontzettend ranzig is geprogrammeerd, net omdat de drempel naar php zo laag is ...

Meestal is de code ook nog niet direct bruikbaar maar moet er eerst een heel deel aan "verhackt" worden voordat ze werkt en daar word ze ook niet meteen beter van, deze code geraakt soms ook opnieuw in circulatie, en soms leren mensen zelfs php aan de hand van die code.

[PrisonerOfPain]

Apache schreef op 06 juli 2004 @ 21:22:
Het zijn de beginners die hun "wauw ik heb net wat geprogrammeerd en het werkt en het is volgens mij fantastisch dus ik ga het releasen zodat anderen het niet meer moeten doen"-code online gooien welke ontzettend ranzig is geprogrammeerd, net omdat de drempel naar php zo laag is ...

Weetje dat ik dat op een manier niet erg vind, je kan namelijk ook die projecten klonen als je niets te doen hebt. Erg ingewikkeld zullen ze niet zijn en dus ben je er ook zo mee klaar. Op alle andere manier heb jij inderdaad gelijk.

[Verwijderd]

Apache schreef op 06 juli 2004 @ 21:22:
[...]
Imo gaat het topic ook hierover, t'is zeker niet de taal op zich die zo ranzig is, goed het is niet perfect, dat weten we allemaal maar wie/wat is dat wel.

Inkoppertje: Haskell, zie mijn sig. voor argumenten. Naja, perfect, it comes close.... Als je je hele leven alleen PHP hebt gezien wordt het denk ik wel een lang reisje voor je het doorhebt...

[Soultaker]

Laten we er geen talendiscussietopic van maken. Het onderwerp van discussie is specifiek PHP en de manier waarop daarin code wordt geschreven.

[djluc]

Er zijn geen standaarden voor het ontwerpen van een app. Behalve dan OOP wat je als echte standaard kunt zien. Dit is echter in PHP4, want in die tijd leven we nog, niet mogelijk. Andere basis-standaarden zijn mij niet echt bekend. Object gebaseerd werken is met een dergelijke scripttaal eigenlijk de enige mogelijkheid. Dit ten opzichte van, ja een simpel voorbeeldje, JavaScript welke ook event-based kan werken.

[Soultaker]

Je kunt in PHP ook procedureel werken. De hele standard library steekt op die manier in elkaar (en op de inconsequente naamgeving na werkt die toch best aardig).

[djluc]

Soultaker schreef op 07 juli 2004 @ 00:38:
Je kunt in PHP ook procedureel werken. De hele standard library steekt op die manier in elkaar (en op de inconsequente naamgeving na werkt die toch best aardig).

Kan je me een voorbeeldje geven hoe je dat dan handig aanpakt? Zeker bij grotere projecten zou het gewoon enorm handig zijn als je goed OOP iets kunt ontwikkelen, maar hoe je procedureel ook een handige opzet kunt maken zie ik niet echt.

[Janoz]

Djluc, je bent van alles door elkaar aan het halen. Procedureel ontwikkelen in php is heel simpel aangezien php een procedurele taal is, net als java een object georienteerde en lisp functionele taal is.

'Standaarden voor het ontwerpen van een app' is absoluut niet het rijtje waar OO in thuis hoort. Hierbij zou ik meer aan frameworks en design patterns denken. Deze zijn legio aanwezig.

En mbt grote projecten procedureel opzetten? Trek de source van linux eens open en kijk hoe dat werkt.

[.oisyn]

Apache schreef op 06 juli 2004 @ 21:22:
Het zijn de beginners die hun "wauw ik heb net wat geprogrammeerd en het werkt en het is volgens mij fantastisch dus ik ga het releasen zodat anderen het niet meer moeten doen"-code online gooien welke ontzettend ranzig is geprogrammeerd, net omdat de drempel naar php zo laag is ...

Daar geef ik je gelijk in, en dat is ook wat ik erkende in mijn eerste post in deze draad ([rml].oisyn in "[ PHP] (te)veel brakke code"[/rml]). Alleen wat ik ook zei is dat wat netheid betreft php sowieso achter blijft op de andere (serieuze) talen (met uitzondering van perl dan ), door al z'n ranzige constructies en onvolkomenheden