[alg] Slechtste programmeervoorbeelden deel 2

[netvor]

Oeps...nou dan heb ik bij deze een mooie entry voor "Slechtste programmeervoorbeelden" :-P
Zelf gebruik ik dit soort constructies nooit in C, ik vind ze niet netjes.
* netvor doet het liefst #include <vector>

[bigbeng]

Wat ik net toch vond:

SQL:

SELECT TOP 100 PERCENT *
FROM MYTABLE

[kenneth]

Zie je in MSSQL-omgevingen wel vaker. In een view kan je (logischerwijs) geen sorteervolgorde opgeven. Er is een workaround (bovenstaande) waar dat wel kan:

SQL:

CREATE VIEW foobar AS SELECT TOP 100 PERCENT * FROM foo ORDER BY bar

Ongedocumenteerd, want het werkt in MSSQL2005 niet meer
Als in: het kan nog wel, maar de returnvolgorde is niet gegarandeerd.

[ Voor 10% gewijzigd door kenneth op 08-03-2007 11:21 ]

[RobIII]

kenneth schreef op donderdag 08 maart 2007 @ 11:21:
Zie je in MSSQL-omgevingen wel vaker. In een view kan je (logischerwijs) geen sorteervolgorde opgeven. Er is een workaround (bovenstaande) waar dat wel kan:

SQL:

CREATE VIEW foobar AS SELECT TOP 100 PERCENT * FROM foo ORDER BY bar

Ongedocumenteerd, want het werkt in MSSQL2005 niet meer
Als in: het kan nog wel, maar de returnvolgorde is niet gegarandeerd.

SQL:

CREATE VIEW foobar AS SELECT TOP 100 PERCENT * FROM foo ORDER BY NewID()

[kenneth]

Zelfde effect ja (in 2005)

[MBV]

Ok, stel je de volgende code eens voor:

PHP:

//...
Example::run($blaat);
//...

class Example {
  function run($var)
  {
    if (!isset($this)) {
      $thiss = 'this';
      $$thiss = new Example;
    }
    $this->doeiets($var);
  }
  //...
}

Wat is nu het probleem met de conversie van PHP4 naar PHP5? In PHP5 geeft hij soms een foutmelding, waar komt dat van Iemand een idee?

[flashin]

DUhhh de functie doeiets(); bestaat niet in de class!

Hahaha .. Eerste keer sinds het windowscommentaar dat ik weer eens dubbel lig om code..

Ik heb zelf geen programmeervoorbeeldjes die niet kloppen, aangezien ik uiteraard briljant programmeer en geen fouten maak..

[ Voor 11% gewijzigd door flashin op 13-03-2007 12:40 ]

[HawVer]

Brrr.. wat ik nou toch weer voor constructie tegenkwam in Delphi. Heeft geen uitleg nodig denk ik.

Delphi:

qryRegels.First;
while not qryRegels.EOF do
begin
   DoeIetsMetRegel;
   if check then
   begin
      qryRegels.Next;
      Continue;
   end;
   if check then
   begin
      if check then
      begin
         qryRegels.Next;
         Continue;   
      end;      
   end;
   DoeIetsMetRegel;
   if check then
   begin
      if check then
      begin
         qryRegels.Next;
         Continue;   
      end;      
   end;
   DoeIetsMetRegel;
   qryRegels.Delete;        
end;

[MBV]

flashin schreef op dinsdag 13 maart 2007 @ 12:37:
DUhhh de functie doeiets(); bestaat niet in de class!

Hahaha .. Eerste keer sinds het windowscommentaar dat ik weer eens dubbel lig om code..

Ik heb zelf geen programmeervoorbeeldjes die niet kloppen, aangezien ik uiteraard briljant programmeer en geen fouten maak..

Waar zie jij de sluitende accolade van de functie? Uiteraard heb ik wat namen aangepast en ingekort, maar ik neem aan dat je het idee snapt... we gaan een $this maken terwijl het statisch is aangeroepen, en dat mag niet. Waarom niet? Misschien omdat je dan je design even moet overdenken?

edit:
even aangepast. Probleempje: ik ben te erg vim-verslaafd, ik zat na die aanpassing dus vrolijk :wq in te tikken En we gaan binnenkort over op .NET met VS 200*, dat wordt lachen...

[ Voor 12% gewijzigd door MBV op 13-03-2007 13:52 ]

[AtleX]

MBV schreef op dinsdag 13 maart 2007 @ 13:51:
[...]

edit:
even aangepast. Probleempje: ik ben te erg vim-verslaafd, ik zat na die aanpassing dus vrolijk :wq in te tikken En we gaan binnenkort over op .NET met VS 200*, dat wordt lachen...

Klinkt heel bekend, code die in niet wil compileren omdat je vergeten bent dat je even in een andere editor zit er dus vrolijk vim commando's hebt getypt.

[Erkens]

ah, ik ben niet de enige die dat dus doet
het is al zelfs zo erg dat ik in bash een alias gemaakt hebt:

Bash:

alias :wq=exit

[mithras]

Erkens schreef op dinsdag 13 maart 2007 @ 14:00:
ah, ik ben niet de enige die dat dus doet
het is al zelfs zo erg dat ik in bash een alias gemaakt hebt:

Bash:

alias :wq=exit

ge-ni-aal, serieus

Kennelijk zijn er toch meer mensen die struikelen over de niet- capabelheid van de rest van je systeem

[Woy]

Een collega van mij hier heeft dan ook een VIM plugin voor zijn visual studio 2005 geinstalleerd

[MBV]

rwb schreef op dinsdag 13 maart 2007 @ 15:34:
Een collega van mij hier heeft dan ook een VIM plugin voor zijn visual studio 2005 geinstalleerd

Is die er ook voor Eclipse?

Goeie trouwens, zal de overstap naar visual studio een stuk makkelijker maken Kan je dan ook net zo irritant met 5 schermen in 1 scherm werken? (:sp, :vsp)

[ Voor 24% gewijzigd door MBV op 13-03-2007 16:07 ]

[Robtimus]

MBV schreef op dinsdag 13 maart 2007 @ 12:19:

PHP:

      $thiss = 'this';
      $$thiss = new Example;

Deze omslachtige manier van "$this = new Example;" vind ik ook al een behoorlijke WTF.

[MBV]

IceManX schreef op dinsdag 13 maart 2007 @ 16:11:
[...]

Deze omslachtige manier van "$this = new Example;" vind ik ook al een behoorlijke WTF.

Waarom denk je dat het nodig is? Ik denk dat PHP gaat flippen als je $this = new Example; neerzet in een klasse. Dat kan namelijk NOOIT! Met $$thiss = new Example omzeil je de check daarop in de compiler, en in 4.x werkt het dus ook

[Woy]

MBV schreef op dinsdag 13 maart 2007 @ 16:17:
[...]

Waarom denk je dat het nodig is? Ik denk dat PHP gaat flippen als je $this = new Example; neerzet in een klasse. Dat kan namelijk NOOIT! Met $$thiss = new Example omzeil je de check daarop in de compiler, en in 4.x werkt het dus ook

Ja wel mooie manier
kan je nog beter iets als het volgende doen als je nou perse zoiets wil doen

PHP:

if( isset($this) )
    $var = $this;
else
    $var = new Example();
$var->DoeIets();

Maar dat neemt nog niet weg dat als iets niet static bedoeld is dat je het ook niet zo moet implementeren

[Woy]

MBV schreef op dinsdag 13 maart 2007 @ 16:06:
[...]

Is die er ook voor Eclipse?

Goeie trouwens, zal de overstap naar visual studio een stuk makkelijker maken Kan je dan ook net zo irritant met 5 schermen in 1 scherm werken? (:sp, :vsp)

Ik weet het niet. Ik heb zelf nooit met VIM gewerkt maar volgens mij is dit hem http://www.viemu.com/

[Voutloos]

MBV schreef op dinsdag 13 maart 2007 @ 16:17:
[...]

Waarom denk je dat het nodig is? Ik denk dat PHP gaat flippen als je $this = new Example; neerzet in een klasse. Dat kan namelijk NOOIT! Met $$thiss = new Example omzeil je de check daarop in de compiler, en in 4.x werkt het dus ook

Eenvoudige regel: Bij gepruts met $$ gebruik in PHP mag geslagen worden.

[MBV]

rwb schreef op dinsdag 13 maart 2007 @ 16:31:
[...]

Ja wel mooie manier
kan je nog beter iets als het volgende doen als je nou perse zoiets wil doen

PHP:

if( isset($this) )
    $var = $this;
else
    $var = new Example();
$var->DoeIets();

Maar dat neemt nog niet weg dat als iets niet static bedoeld is dat je het ook niet zo moet implementeren

Dat was ook precies hoe ik het heb gefixed. Iets minder slecht.
* MBV bedenkt zich ineens dat hij is vergeten dat $var =& $this de oplossing 20x minder smerig maakt . Nu is het zo dat $var->member = 'foo' ervoor zorgt dat die alleen tijdelijk veranderd wordt.

Gelukkig wordt die klasse alleen maar als namespace gebruikt

edit:
[quote]Voutloos schreef op dinsdag 13 maart 2007 @ 16:51:
[...]
Eenvoudige regel: Bij gepruts met $$ gebruik in PHP mag geslagen worden.
[/quote]
Dat is heel lastig, ik weet niet waar hij nu woont. Ik zou hem op kunnen wachten bij zijn nieuwe werkgever maar over het algemeen is zijn excuus dat het eraan ligt dat de troep-code ouder is dan dat hij hier begon met werken. Jaja

Groot nieuws! Dit heeft hij ECHT zelf gedaan, in PHP4 werkte $this = new Object; namelijk nog gewoon, hij heeft de uber-ranzige hack met $$thiss geschreven! Lang leve SVN!

Fix for handling in php5

was zijn opmerking erbij

En nog mooier: Hij heeft ook de $this = new Object-regel geschreven! Mag ik nu echt gaan slaan? Voorlopig nog geen recommendation voor LinkedIn

[ Voor 36% gewijzigd door MBV op 13-03-2007 17:34 ]

[Anoniem: 14829]

rwb schreef op dinsdag 13 maart 2007 @ 16:31:

PHP:

if( isset($this) )
    $var = $this;
else
    $var = new Example();
$var->DoeIets();

Maar dat neemt nog niet weg dat als iets niet static bedoeld is dat je het ook niet zo moet implementeren

2 Dingen:
- Wie zegt dat 't static bedoeld is? Met m'n beperkte PHP kennis schat ik in dat 't een singleton benadering is.
- Jouw 'oplossing' geeft altijd een nieuwe instance terug wanneer $this niet is geset. Via die $$thiss hack wordt $this eenmalig geset, en is bij iedere volgende aanroep het else-gedeelte niet meer van belang, $this bestaat namelijk al.

Lelijke oplossing, dat wel, maar m.i. ligt dat meer in de beperkingen van de taal dan in het oplossend vermogen van de programmeur...

[MBV]

Anoniem: 14829 schreef op dinsdag 13 maart 2007 @ 22:20:
[...]

2 Dingen:
- Wie zegt dat 't static bedoeld is? Met m'n beperkte PHP kennis schat ik in dat 't een singleton benadering is.

Dit is geen echte singleton benadering. Een singleton benadering zou zoiets zijn:

PHP:

class Example
{

  /*****************
   *!!!DEZE CONSTRUCTOR NOOIT GEBRUIKEN!!!
   * (sorry, php4 heeft geen private ;)
   *****************/
  function Example()
  {
    //...
  }
  
  function &GetInstance()
  {
    static $instance;
    if (!is_object($instance)) $instance = new Example();
    return $instance;
  }

  function run($var)
  {
    $this->doeIets();
  }
  //...
}

$l_oExample = Example::GetInstance();
$l_oExample->run('blaat');

Dus bij een singleton hoef je niet te kloten met $this iets toewijzen. En er hoeft niet elke keer een nieuw object te worden aangemaakt, en het is een stuk leesbaarder. Enige nadeel is dat je bij de aanroep 2 regels nodig hebt ipv 1.

- Jouw 'oplossing' geeft altijd een nieuwe instance terug wanneer $this niet is geset. Via die $$thiss hack wordt $this eenmalig geset, en is bij iedere volgende aanroep het else-gedeelte niet meer van belang, $this bestaat namelijk al.

$$thiss-hack doet precies hetzelfde als wat hij beschrijft. Met $thiss = 'this' wordt een string in $thiss gegooid. $$thiss = new Example() evalueert die string naar een variabelenaam, en gebruikt die vervolgens. Zelfde effect als $this = new Example(), maar dan met truc om PHP5 voor de gek te houden.

Lelijke oplossing, dat wel, maar m.i. ligt dat meer in de beperkingen van de taal dan in het oplossend vermogen van de programmeur...

De taalbeperkingen zijn hier niet van toepassing: hier is gewoon een verkeerd ontwerp (of gebrek aan ontwerp) de schuldige. In Java zal je net zulke smerige streken moeten uithalen om het te laten werken: het druist namelijk in tegen alle OO principes. Een functie is óf static (je hebt geen members nodig om je taak uit te voeren) óf het is een method die de constructor nodig hebt.

In dit geval was er eigenlijk een 2e klasse nodig, die door de eerste af en toe gebruikt werd. Zeg maar een speciale string-klasse. Die klasse werd vervolgens samengeschoven met de oorspronkelijke klasse, et voilá, een stukje supersmerige code is ontstaan

[Anoniem: 14829]

MBV schreef op dinsdag 13 maart 2007 @ 23:00:
Dit is geen echte singleton benadering. Een singleton benadering zou zoiets zijn:

Met "benadering" bedoelde ik "hij probeerde iets in de buurt ... van te bereiken"

$$thiss-hack doet precies hetzelfde als wat hij beschrijft. Met $thiss = 'this' wordt een string in $thiss gegooid. $$thiss = new Example() evalueert die string naar een variabelenaam, en gebruikt die vervolgens. Zelfde effect als $this = new Example(), maar dan met truc om PHP5 voor de gek te houden.

OK, mijn PHP kennis gaat niet zover dat ik dit kon inschatten (maar dat had ik ook al gezegd). Als jouw uitleg klopt (en daar ga ik voetstoots vanuit) dan is 't een flinke zeperd. Maar wel een zeperd waar je van kunt leren en achteraf om kunt lachen.

Een functie is óf static (je hebt geen members nodig om je taak uit te voeren) óf het is een method die de constructor nodig hebt.

Klopt natuurlijk, maar met m'n Delphi achtergrond ben ik gewend aan gewone functies (die niet aan een class gebonden zijn), class functions (vergelijkbaar met static functions in C#) en methods (die een instance van die class nodig hebben).
Maar daar gaat 't niet om, blijkbaar heb ik die PHP code verkeerd geinterpreteerd. Zo leer je elke dag weer wat nieuws...

[MBV]

Anoniem: 14829 schreef op woensdag 14 maart 2007 @ 00:57:
[...]
Met "benadering" bedoelde ik "hij probeerde iets in de buurt ... van te bereiken"

sorry. Met "De [insert methode] benadering" wordt meestal bedoeld dat je dat gewoon gebruikt

[...]
Klopt natuurlijk, maar met m'n Delphi achtergrond ben ik gewend aan gewone functies (die niet aan een class gebonden zijn), class functions (vergelijkbaar met static functions in C#) en methods (die een instance van die class nodig hebben).
Maar daar gaat 't niet om, blijkbaar heb ik die PHP code verkeerd geinterpreteerd. Zo leer je elke dag weer wat nieuws...

Dat is precies wat ik bedoelde. Je gaat geen functie doen die allebei kan

[PrisonerOfPain]

MBV schreef op dinsdag 13 maart 2007 @ 23:00:
Dus bij een singleton hoef je niet te kloten met $this iets toewijzen. En er hoeft niet elke keer een nieuw object te worden aangemaakt, en het is een stuk leesbaarder. Enige nadeel is dat je bij de aanroep 2 regels nodig hebt ipv 1.

Bij een singleton implementatie werkt dit ook:

PHP:

Object::getInstance()->run();

$$thiss-hack doet precies hetzelfde als wat hij beschrijft. Met $thiss = 'this' wordt een string in $thiss gegooid. $$thiss = new Example() evalueert die string naar een variabelenaam, en gebruikt die vervolgens. Zelfde effect als $this = new Example(), maar dan met truc om PHP5 voor de gek te houden.

Het probleem met de code is, natuurlijk, dat 't niet forward compatible is omdat PHP5 al een expliciete melding geeft als je rechtstreeks aan $this toewijst terwijl 't in PHP4 nog wel gewoon mogelijk was. Persoonlijk heb ik ook nooit het nut van dit gedoe begrepen, behalve als leuke experimentjes.
Anyway:

PHP:

${'this'} = new MyObj();

[MBV]

Sommige talen doen moeilijk over dat soort trucs (-> achter functieaanroep) dus ik vermijdt het liever .

[sig69]

Ik kwam net dit tegen in een project waar ik nu mee bezig ben:

C#:

private Session Session
{
    get { return _session; }
    set { _session = value; }
}

En niet een keer, maar meerdere keren. Iemand heeft tijd te veel denk ik...

[Chester]

sig69 schreef op vrijdag 23 maart 2007 @ 18:05:
Ik kwam net dit tegen in een project waar ik nu mee bezig ben:

C#:

private Session Session
{
    get { return _session; }
    set { _session = value; }
}

En niet een keer, maar meerdere keren. Iemand heeft tijd te veel denk ik...

Wat is hier raar aan? Zo schrijf je getters en setters in c# Of mis ik iets?

[AtleX]

Ja, je mist iets. _session is waarschijnlijk al private, normaal gesproken maak je daar een public getter en setter bij op bovenstaande manier. Nu heeft de schrijver van die code 2x een private variabele die exact hetzelfde doen.

[ Voor 22% gewijzigd door AtleX op 23-03-2007 18:35 ]

[Anoniem: 201130]

AtleX schreef op vrijdag 23 maart 2007 @ 18:35:
Ja, je mist iets. _session is waarschijnlijk al private, normaal gesproken maak je daar een public getter en setter bij op bovenstaande manier. Nu heeft de schrijver van die code 2x een private variabele die exact hetzelfde doen.

Zo vreemd is dat op zich nu ook weer niet als je intellisense tools als Resharper gebruikt. Dan is het 2 seconde werk om er een property van te maken.

Of je doet het vanuit de coding guidelines, die prefereren meestal ook properties. Ware het niet dat die persoon in kwestie underscores gebruikt en dat is dus net 1 van de veel voorkomende bad practises wanneer de MS C# coding standards gevolgd worden.

Maar ik ben het wel met je eens dat het overdone is, het is alleen geen slecht programmeervoorbeeld

[AtleX]

Ik gebruik ook underscores om mijn private properties aan te duiden, hoe doe jij het dan?

[Anoniem: 201130]

AtleX schreef op vrijdag 23 maart 2007 @ 20:54:
Ik gebruik ook underscores om mijn private properties aan te duiden, hoe doe jij het dan?

Ik neem aan dat je fields bedoeld?

De correcte syntax volgens de C# Coding guidelines voor properties en fields is:

C#:

private string voorbeeld;

public string Voorbeeld
{
    get  { return voorbeeld; }
    set { voorbeeld = value; }
}

De redenatie hier achter is dat de underscores helemaal niets toevoegen. Overzichtelijker is het ook niet, ookal willen veel mensen je dit doen geloven. Dit zijn vooral mensen die uit "oudere" talen komen, zoals Delphi en C++ waar de underscores, f'jes en m'tjes andere problemen oplosten en dus niet meer dan gewenning zijn. De intellisense en capitalizing die VS standaard biedt, biedt je genoeg onderscheid, tenzij je blind bent, maar dan is programmeren uberhaubt al moeilijk.

Even wat links:
http://blogs.msdn.com/brada/articles/361363.aspx
http://msdn.microsoft.com...cpconnamingguidelines.asp

[ Voor 17% gewijzigd door Anoniem: 201130 op 23-03-2007 21:30 ]

[AtleX]

Anoniem: 201130 schreef op vrijdag 23 maart 2007 @ 21:19:
[...]


Ik neem aan dat je fields bedoeld?

Fields, properties, die namen worden volgens mij overal wel door elkaar gebruikt.

De correcte syntax volgens de C# Coding guidelines voor properties en fields is:

C#:

private string voorbeeld;

public string Voorbeeld
{
    get  { return voorbeeld; }
    set { voorbeeld = value; }
}

De redenatie hier achter is dat de underscores helemaal niets toevoegen. Overzichtelijker is het ook niet, ookal willen veel mensen je dit doen geloven. Dit zijn vooral mensen die uit "oudere" talen komen, zoals Delphi en C++ waar de underscores, f'jes en m'tjes andere problemen oplosten en dus niet meer dan gewenning zijn. De intellisense en capitalizing die VS standaard biedt, biedt je genoeg onderscheid, tenzij je blind bent, maar dan is programmeren uberhaubt al moeilijk.

Even wat links:
http://blogs.msdn.com/brada/articles/361363.aspx
http://msdn.microsoft.com...cpconnamingguidelines.asp

Ik ben ooit begonnen in Pascal, toen doorgegroeid naar Delphi en nu C#, dus ja, bij mij komt het echt uit de 'oude' talen. Ik moet wel zeggen dat jou methode er duidelijker uitziet.

[Woy]

Anoniem: 201130 schreef op vrijdag 23 maart 2007 @ 20:43:
[...]
Of je doet het vanuit de coding guidelines, die prefereren meestal ook properties. Ware het niet dat die persoon in kwestie underscores gebruikt en dat is dus net 1 van de veel voorkomende bad practises wanneer de MS C# coding standards gevolgd worden.

Volgens mij is het volgens de MS C# standard wel gewoon toegestaan om underscores te gebruiken. Over private variabelen staan niet zulke strikte regels in de standaard volgens mij. Zelf doe ik het ieder geval ook niet.

Aangezien ik eigenlijk nooit public/protected fields heb doe ik alle fields gewoon met kleine letters en properties met hoofdletter.
Als ik iets public of protected wil hebben dan maak ik er idd met resharper een property van. Dan kan je eventueel later de implementatie tenminste nog vervangen.

Edit:
Het staat er blijkbaar wel ergens in

Do not apply a prefix to field names or static field names. Specifically, do not apply a prefix to a field name to distinguish between static and nonstatic fields. For example, applying a g_ or s_ prefix is incorrect.

Alleen er is geen apart stukje Field Naming Guidelines, maar het staat bij Field Usage Guidelines.

[ Voor 18% gewijzigd door Woy op 24-03-2007 11:13 ]

[Zoefff]

Erkens schreef op dinsdag 13 maart 2007 @ 14:00:
ah, ik ben niet de enige die dat dus doet
het is al zelfs zo erg dat ik in bash een alias gemaakt hebt:

Bash:

alias :wq=exit

Dat is dan nog redelijk normaal, ik heb er "ciao" van gemaakt

[AndriesLouw]

Ok, even een script van phphulp.nl:

PHP:

<?php
  ///////////////////////////////////
  //id script made bij Oo_dj_tm_oO///
  //www.skateboardmove.nl////////////
  ///////////////////////////////////
//hoeveel namen wil je invullen??
   $hoeveel = 3;
//geef hier de namen van de pagina's in, ZONDER extensie
   $naam = array("naam1", "naam2", "naam3");
//wat is de extensie, zonder punt
   $ext = "html";
// wat moet de link zijn? id, act???
   $l = "id";
//als je alles goed hebt ingevuld doet ie het nu
       $li = $_GET[$l];//even de get-methode maken
    for ($a=0; $a<$hoeveel; $a++) {//iedere naam een apart nummer geven
if($li==$naam[$a]) {//maak pagina
    include $naam[$a].".".$ext;//include de pagina
     }
}
?> 

edit:

Aangeven hoeveel waardes een array heeft, en in plaats van in_array een for loop gebruiken, waren we dat niet al eerder tegengekomen?

[ Voor 11% gewijzigd door AndriesLouw op 25-03-2007 11:04 ]

[Reinier]

even de get-methode maken

Dat is commentaar waar je wat aan hebt

[prototype]

AndriesLouw schreef op zondag 25 maart 2007 @ 10:59:
Ok, even een script van phphulp.nl:

PHP:

<?php
  ///////////////////////////////////
  //id script made bij Oo_dj_tm_oO///
  //www.skateboardmove.nl////////////
  ///////////////////////////////////
//hoeveel namen wil je invullen??
   $hoeveel = 3;
//geef hier de namen van de pagina's in, ZONDER extensie
   $naam = array("naam1", "naam2", "naam3");
//wat is de extensie, zonder punt
   $ext = "html";
// wat moet de link zijn? id, act???
   $l = "id";
//als je alles goed hebt ingevuld doet ie het nu
       $li = $_GET[$l];//even de get-methode maken
    for ($a=0; $a<$hoeveel; $a++) {//iedere naam een apart nummer geven
if($li==$naam[$a]) {//maak pagina
    include $naam[$a].".".$ext;//include de pagina
     }
}
?> 

edit:

Aangeven hoeveel waardes een array heeft, en in plaats van in_array een for loop gebruiken, waren we dat niet al eerder tegengekomen?

De comments, vooral in aantal en het weinig nuttig zijn ervan hier, vind ik hier meer een WTF. Het wel of niet gebruiken van in_array doet er niet zoveel aan toe (computational zal het w.s. toch wel een lineaire search betekenen) als men hier nog een guard had gebruikt om uit de for lus te breken als men het gewenste heeft gevonden, i.e. $li == $naam[$a].

[farlane]

Anoniem: 201130 schreef op vrijdag 23 maart 2007 @ 21:19:
... De correcte syntax ....

De syntax is in beide gevallen correct.

De redenatie hier achter is dat de underscores helemaal niets toevoegen.

Wat maakt het uit of je afspreekt dat je members met een kleine letter gaat schrijven of er een prefix voorzet? Hoe gaat dit verschil betere of slechtere software opleveren?

[kenneth]

Het enige wat erg is, is als je de underscore gebruikt, en dan weer 'n m-prefix en dan weer 'n underscore ... enz.

[Anoniem: 201130]

farlane schreef op zondag 25 maart 2007 @ 15:04 Hoe gaat dit verschil betere of slechtere software opleveren?

Dat beweer ik toch ook nergens? Theoretisch gezien levert het slechter onderhoudbare code op, omdat het niet de standaard volgt. Maar dat is natuurlijk echter ook onzinnig.

Het is echter niet volgens de standaard en mag dus als een slecht programmeervoorbeeld gezien worden, echter zul je in elke applicatie dingen tegen komen die niet volgens standaard zijn. Is het discutabel: Ja. Is het onzinnig om hierover te discusseren: Ja, immers schrijft de standaard voor geen prefixes te gebruiken en voegen ze ook daadwerkelijk niets meer toe.

De enige goede code, is werkende code naar de maatstaven van de klant.

[ Voor 10% gewijzigd door Anoniem: 201130 op 25-03-2007 16:14 ]

[Anoniem: 112721]

Anoniem: 201130 schreef op zondag 25 maart 2007 @ 16:12:
[...]
omdat het niet de standaard volgt.

MS heeft alleen een naming guideline voor de publieke interface neergelegd, dus je mag zelf bepalen of je wel of geen prefix voor private fields gebruikt.

Ik persoonlijk kies wel voor een prefix, omdat zonder prefix IMHO 'buggevoeliger' is: bijv. type je per ongeluk een hoofdletter (o.a. door intellisense) in een property, dan zit je met een oneindige loop.

[Anoniem: 201130]

Anoniem: 112721 schreef op zondag 25 maart 2007 @ 17:39:
[...]

MS heeft alleen een naming guideline voor de publieke interface neergelegd, dus je mag zelf bepalen of je wel of geen prefix voor private fields gebruikt.

Ik persoonlijk kies wel voor een prefix, omdat zonder prefix IMHO 'buggevoeliger' is: bijv. type je per ongeluk een hoofdletter (o.a. door intellisense) in een property, dan zit je met een oneindige loop.

Dat betekent dus dat jij geen unit tests uitvoert en bovendien moet je behoorlijk slechte ogen hebben om dankzij de intellisense en hoofdletters niet te zien dat je een fout maakt. Het kan dus onmogelijk buggevoeliger zijn, tenzij je je eigen code niet afdoende test.

Daarnaast zijn naming conventies bedoeld om ze op te volgen en de code globaal te standariseren waarin uitdrukkelijk wordt aangegeven ze niet te gebruiken.

[ Voor 26% gewijzigd door Anoniem: 201130 op 25-03-2007 17:45 ]

[sky-]

Ik kwam laatst deze onzin tegen op een forum :

PHP:

<?php
while (1 == 1)
{
 // haal berichten op..
}
?>

En die gozert maar afvragen waarom het niet werkte..

[Erkens]

k8skaaay schreef op zondag 25 maart 2007 @ 18:08:
Ik kwam laatst deze onzin tegen op een forum :

PHP:

<?php
while (1 == 1)
{
 // haal berichten op..
}
?>

En die gozert maar afvragen waarom het niet werkte..

als dat alle code is binnen die loop dat is gewoon een bug, niet echt een slecht programmeervoorbeeld
er is opzich niks mis met een endless loop imo

[whoami]

AtleX schreef op zaterdag 24 maart 2007 @ 11:04:
[...]

Fields, properties, die namen worden volgens mij overal wel door elkaar gebruikt.

Nee, er is wel degelijk een verschil tussen een field & een property in .NET, en je moet dus opletten dat je ieder beestje met de juiste naam aanspreekt.

sig69 schreef op vrijdag 23 maart 2007 @ 18:05:
Ik kwam net dit tegen in een project waar ik nu mee bezig ben:

C#:

private Session Session
{
    get { return _session; }
    set { _session = value; }
}

En niet een keer, maar meerdere keren. Iemand heeft tijd te veel denk ik...

Tja, eigenljk is er niets raars aan (doe ik soms ook), maar het is idd nogal omslachtig saai, maar gelukkig is dat in C# 3.0 opgelost met

code:

public int Blaat
{
   get;
   set;
}

edit: Oops, zie nu pas dat die property ook private is ? Tja, dan ontgaat het doel me ook wel een beetje.

Volgens mij is het volgens de MS C# standard wel gewoon toegestaan om underscores te gebruiken. Over private variabelen staan niet zulke strikte regels in de standaard volgens mij. Zelf doe ik het ieder geval ook niet.

Ik gebruik ook underscores bij m'n private fields, en FXCop heeft er nog nooit over geklaagd.

Het is echter niet volgens de standaard en mag dus als een slecht programmeervoorbeeld gezien worden,

Welke standaard ? Het is toch niet omdat MS een guideline of standaard vooropstelt, dat je daarom verplicht bent die std te volgen / gebruiken ?
Bedrijven hebben meestal hun eigen guidelines / standard, en die standaard kan best gebaseerd zijn op de MS guidelines, maar als de Std van dat bedrijf zegt: private fields beginnen met een underscore, dan is het pas fout als jij dat stug niet doet, omdat MS zegt dat het niet 'mag'. Dan pas wordt het voor jouw collega's moeilijker begrijpbaar

[ Voor 86% gewijzigd door whoami op 25-03-2007 19:15 ]

[Anoniem: 201130]

whoami schreef op zondag 25 maart 2007 @ 19:02:
Welke standaard ? Het is toch niet omdat MS een guideline of standaard vooropstelt, dat je daarom verplicht bent die std te volgen / gebruiken ?
Bedrijven hebben meestal hun eigen guidelines / standard, en die standaard kan best gebaseerd zijn op de MS guidelines, maar als de Std van dat bedrijf zegt: private fields beginnen met een underscore, dan is het pas fout als jij dat stug niet doet, omdat MS zegt dat het niet 'mag'. Dan pas wordt het voor jouw collega's moeilijker begrijpbaar

Ik heb bedrijfsguidelines inderdaad er buiten gehouden. Eerst idd voldoen aan de standaard van het bedrijf waar je voor werkt, daarna pas aan de algemene guidelines.

whoami schreef op zondag 25 maart 2007 @ 19:02:
[...]
Ik gebruik ook underscores bij m'n private fields, en FXCop heeft er nog nooit over geklaagd.

Dat ligt natuurlijk ook aan je FXCop ruleset . De standaard MS sets zijn overigens minder strikt dan hun guidelines.

[ Voor 17% gewijzigd door Anoniem: 201130 op 25-03-2007 19:27 ]

[farlane]

Kweenie maar volgens mij haal je standaard en guidelines door elkaar.

[Anoniem: 201130]

farlane schreef op zondag 25 maart 2007 @ 22:51:
Kweenie maar volgens mij haal je standaard en guidelines door elkaar.

Dat ligt aan de definitie van standaard. Als je beweert dat je aan een guideline voldoet dan is het voor jouw een standaard waaraan je moet voldoen. Als je dus beweert dat je c# op de standaard manier doet en je prefixed dan voldoe je er dus niet aan.

Zeg je echter dat je het als een richtlijn gebruikt dan is het inderdaad wat anders. Het klopt dat de .NET coding guidelines niet zoiets als ISO certificeringen zijn om de naam te mogen dragen. Je kunt het echter wel vergelijken met de HTML standaard... Beetje dubieus dus qua gebruik, dat geef ik toe. De echte vraag is echter: "Wanneer is iets een standaard? Wanneer 1 of andere council vind dat het een standaard wordt?".

Alleen roepen vrijwel alle bedrijven die .NET doen, dat ze aan de door MS gestelde richtlijnen/standaarden volgen en dat betekent dus dat ze de guideline verheffen tot standaard. Echter gaan ze vervolgens wel gewoon lekker prefixen en dat kan dus niet als ze het zouden volgen.

[ Voor 5% gewijzigd door Anoniem: 201130 op 25-03-2007 23:31 ]

[.oisyn]

Anoniem: 201130 schreef op zondag 25 maart 2007 @ 23:29:
Als je dus beweert dat je c# op de standaard manier doet en je prefixed dan voldoe je er dus niet aan.

De guidelines voor C# zeggen niets over het al dan niet prefixen van private fields. Een van de artikelen die jij eerder aanhaalde waar iets stond over de naamgeving van private fields ging om de interne guidelines die de ontwikkelaars van het framework zelf gebruiken. En die kun je nauwelijks als "standaard" aanmerken - niet iedereen is immers .Net standaard framework ontwikkelaar. Als je het over de "standaard" .Net guidelines hebt, dan heb je het over die passages in de MSDN, en daar staat alleen iets in over de publieke interface design van je library.

[ Voor 8% gewijzigd door .oisyn op 26-03-2007 00:06 ]

[MueR]

Ik loop momenteel tegen het volgende stukje code aan op het werk (nog een keer tijd maken om het goed te schrijven). Dit is een baksel van degene die voor mij het programmeerwerk deed.
Het doel van deze code is een 5 cijferige code genereren, en er zeker van zijn dat deze niet al in gebruik is. Het zijn namelijk telefoon betaalcodes.

PHP:

function generatePhoneCode() {
  $random = rand(10000, 99999);
  $sql = "SELECT * FROM tbl_micropayment_code WHERE mpc_code != '$random'";
  $result = mysqlx_query($sql);
  if (mysql_num_rows($result) > 0)
  {
    $random = 0;
  }
  return $random;
}
$random = 0;
while ($random == 0)
{
  $random = generatePhoneCode();
}

Toen hij mij in aan het werken was vroeg ik waarom hij dit ooit zo gedaan had. "Niks mis mee toch?" zegt ie vrolijk...

[Anoniem: 201130]

.oisyn schreef op maandag 26 maart 2007 @ 00:05:
[...]

De guidelines voor C# zeggen niets over het al dan niet prefixen van private fields. Een van de artikelen die jij eerder aanhaalde waar iets stond over de naamgeving van private fields ging om de interne guidelines die de ontwikkelaars van het framework zelf gebruiken. En die kun je nauwelijks als "standaard" aanmerken - niet iedereen is immers .Net standaard framework ontwikkelaar. Als je het over de "standaard" .Net guidelines hebt, dan heb je het over die passages in de MSDN, en daar staat alleen iets in over de publieke interface design van je library.

Wel degelijk: http://msdn.microsoft.com...nfieldusageguidelines.asp


Het staat onder Field Usage Guidelines, is overigens een paar posts geleden door iemand anders al opgemerkt dat het daar staat.

• Do not use Hungarian notation for field names. Good names describe semantics, not type.
• Do not apply a prefix to field names or static field names. Specifically, do not apply a prefix to a field name to distinguish between static and nonstatic fields. For example, applying a g_ or s_ prefix is incorrect.

[ Voor 18% gewijzigd door Anoniem: 201130 op 26-03-2007 00:27 ]

[sig69]

Ach, we hebben hier intern nu eenmaal afgesproken dat we een _ prefix gebruiken voor private fields. Ik zit er niet zo mee. De WTF in het stukje dat ik poste was inderdaad de private property, die dus helemaal niets toevoegd.

[farlane]

Anoniem: 201130 schreef op maandag 26 maart 2007 @ 00:23:
Wel degelijk: http://msdn.microsoft.com...nfieldusageguidelines.asp
[...]

Die link die je geeft is voor class library developers. ( zie de post van .oisyn )

Anywayz, het maakt allemaal weinig uit natuurlijk. Het belangrijkste is dat je consistent bent in je coding of je nu wel of niet een prefix gebruikt.

Ik zou je wel willen aanraden om bij alles wat je leest over programmeren en dat soort dingen je telkens goed de vragen te stellen of het je (/jouw klant ) wat oplevert en of het wel pragmatisch ( http://www.pragmaticprogrammer.com/ppbook/index.shtml ) is om het te doen zoals het geschreven staat. Er wordt naast een heleboel bere goeie informatie ook een heleboel geschreven om maar wat op te schrijven.

[Anoniem: 201130]

farlane schreef op maandag 26 maart 2007 @ 08:56:
[...]


Die link die je geeft is voor class library developers. ( zie de post van .oisyn )

Lijkt me ook niet dat je in de web of win project fields en properties gaat introduceren? Je zult er vast wel een paar gebruiken, maar het merendeel zie je toch echt terug in je class libraries. En je gaat niet verschillende coding stijlen gebruiken om je BLL van de DAL te onderscheiden (Dat zou wel goed in dit topic passen ).

En de rest had ik zelf ook al eerder aangegeven . Als coding guidelines het belangrijkste was waar je je elke dag mee bezig moest houden, kon je als programmeur beter vuilsnisman worden.

[ Voor 10% gewijzigd door Anoniem: 201130 op 26-03-2007 18:36 ]

[LiquidSmoke]

Ik heb serieus eens mijn hoofd gebroken over het volgende

Visual Basic:

For i = 1 to 10
     Text1(i).text = iets
     i = i + 1
Next

En je dan serieus afvragen waarom je waardes zo gek ingevuld worden

[ Voor 0% gewijzigd door LiquidSmoke op 26-03-2007 22:11 . Reden: is al wel een heeeeele tijd geleden hoor :) ]

[Robtimus]

Wat dacht je, je was de increment al zo vaak vergeten in while loops dat je hem maar een keer extra in de for zet?

[NielsNL]

LiquidSmoke schreef op maandag 26 maart 2007 @ 22:10:
Ik heb serieus eens mijn hoofd gebroken over het volgende

Visual Basic:

For i = 1 to 10
     Text[b]1[/b](i).text = iets
     i = i + 1
Next

En je dan serieus afvragen waarom je waardes zo gek ingevuld worden

Daar zat de fout?
Ik zie alleen het nut niet om 10 text veldjes te vullen met "iets".
* NielsNL ziet opmerking hierboven en whacks himself...

[ Voor 5% gewijzigd door NielsNL op 26-03-2007 22:54 ]

[kenneth]

Goeie ouwe VB-tijd was dat he ...

Visual Basic:

While not rs.EOF
   DoSomethingWith rs
Wend

Tight loop ... ohja, de rs.MoveNext

[Robtimus]

kenneth schreef op maandag 26 maart 2007 @ 23:01:
Goeie ouwe VB-tijd was dat he ...

Visual Basic:

While not rs.EOF
   DoSomethingWith rs
Wend

Tight loop ... ohja, de rs.MoveNext

Die fout heb ik vaak zat gemaakt. Vooral omdat ik vaker in Java programmeer, en daar is de check + het move next in 1 functie gebouwd. Dus:

Java:

while (rs.next()) {
    doSomethingWith(rs);
}

En dan ga je in VB/ASP proggen en vergeet je idd de MoveNext. En ik me maar afvragen waarom de ASP pagina's zo traag zijn...

[LiquidSmoke]

Het ergste is nog dat je vaak in eerste instantie niet ziet wat je nu fout doet, wanneer je een half uur later er achter komt wat er nou misgaat besef je vaak ook dat het 4u snachts is en je moet gaan slapen...

[Paul]

Nah, die fout heb ik al zovaak gemaakt

Run in debugger -> "Hmm, duurt la.. ^%*#%$#$% BlaTable.Next! "

[prototype]

IceManX schreef op dinsdag 27 maart 2007 @ 09:03:
[...]

Die fout heb ik vaak zat gemaakt. Vooral omdat ik vaker in Java programmeer, en daar is de check + het move next in 1 functie gebouwd. Dus:

Java:

while (rs.next()) {
    doSomethingWith(rs);
}

En dan ga je in VB/ASP proggen en vergeet je idd de MoveNext. En ik me maar afvragen waarom de ASP pagina's zo traag zijn...

Als rs een iterator is moet je eerst checken uiteraard of er wel een volgende is voordat je refereert naar de volgende, scheelt je een mogelijke exceptie. Gebruik makend van short circuited evaluation van de guard levert het dan zoiets op als:

Java:

while(rs.hasNext() && (toet = rs.next()) {
    //doe iets met toet
}

Verder heb je sinds java5 gewoon een foreach construct en icm generics die typesafety kunnen garanderen is het een piece of cake om hierdoor te werken:

Java:

for(EenType bla : rs) {
    //doe je ding
}

Voorwaarde voor rs is dan dat deze Iterable<EenType> (of covariant, i.e. Iterable<? extends EenType>) is, oftewel, een iterator terug kan geven voor de foreach.

LiquidSmoke schreef op dinsdag 27 maart 2007 @ 17:41:
Het ergste is nog dat je vaak in eerste instantie niet ziet wat je nu fout doet, wanneer je een half uur later er achter komt wat er nou misgaat besef je vaak ook dat het 4u snachts is en je moet gaan slapen...

Hier hebben ze dan ook debuggers voor uitgevonden Enige wat je moet weten is een vermoeden waar het fout gaat (hoeft niet perse de plek te zijn waar het fout gaat, zolang het maar een plek is VOORDAT het fout gaat). Zet daar je breakpoint op en step door je code heen.

[ Voor 31% gewijzigd door prototype op 27-03-2007 18:02 ]

[Robtimus]

prototype schreef op dinsdag 27 maart 2007 @ 17:56:
[...]


Als rs een iterator is moet je eerst checken uiteraard of er wel een volgende is voordat je refereert naar de volgende, scheelt je een mogelijke exceptie. Gebruik makend van short circuited evaluation van de guard levert het dan zoiets op als:

Java:

while(rs.hasNext() && (toet = rs.next()) {
    //doe iets met toet
}

rs.next() doet dus allebei: als er nog een record is, gaat ie daarnaartoe en returnt ie true. Anders returnt ie false.

Het is niet een gewone java.util.Iterator waarbij dit idd fout gaat.

[Anoniem: 142961]

MueR schreef op maandag 26 maart 2007 @ 00:19:
Ik loop momenteel tegen het volgende stukje code aan op het werk (nog een keer tijd maken om het goed te schrijven). Dit is een baksel van degene die voor mij het programmeerwerk deed.
Het doel van deze code is een 5 cijferige code genereren, en er zeker van zijn dat deze niet al in gebruik is. Het zijn namelijk telefoon betaalcodes.

PHP:

function generatePhoneCode() {
  $random = rand(10000, 99999);
  $sql = "SELECT * FROM tbl_micropayment_code WHERE mpc_code != '$random'";
  $result = mysqlx_query($sql);
  if (mysql_num_rows($result) > 0)
  {
    $random = 0;
  }
  return $random;
}
$random = 0;
while ($random == 0)
{
  $random = generatePhoneCode();
}

Toen hij mij in aan het werken was vroeg ik waarom hij dit ooit zo gedaan had. "Niks mis mee toch?" zegt ie vrolijk...

Afgezien van het feit dat de uniciteit van de phonecode niet bepaald gewaarborgd wordt (het random getal dat ervoor zorgt dat je uit de while loop komt is precies gelijk aan een al bestaande random getal, of je hangt ), is dit voorbeeld ook goed voor het testen van concurrency problemen.

Als je dit m.i. niet in een transactie duwt, kan het voorkomen dat twee (of meerdere) gebruikers tegelijk eenzelfde random getal krijgen. Al is de kans volgens mij klein. Ik heb eens eerder een soortgelijke code gebruikt, maar dan met het bepalen van een maximum en vervolgens verhogen met 1. Ik kreeg het toen niet voor elkaar om in twee verschillende browsers (en dus sessies) hetzeflde getal te krijgen (F5, F5, F5, F5 ). Iemand ervaring mee?

[Icelus]

Kwam deze op Code Project tegen:

Visual Basic:

IF a=1 AND a<>2 and a<>3 and a<>4 THEN ...

Bron

[Voutloos]

Prachtig. Zeker omdat AND geen short-circuit doet in VB, dus alle checks worden ook echt uitgevoerd.

[Sh0ckTr00per]

PHP:

$add = '';

if ($maat_upd == 50)
    $add .= '<OPTION SELECTED VALUE=50>50</OPTION>';
ELSE
    $add .= '<OPTION VALUE=50>50</OPTION>';
if ($maat_upd == 62)
    $add .= '<OPTION SELECTED VALUE=62>62</OPTION>';
ELSE
    $add .= '<OPTION VALUE=62>62</OPTION>';
if ($maat_upd == 74)
    $add .= '<OPTION SELECTED VALUE=74>74</OPTION>';
ELSE
    $add .= '<OPTION VALUE=74>74</OPTION>';
if ($maat_upd == 86)
    $add .= '<OPTION SELECTED VALUE=86>86</OPTION>';
ELSE
    $add .= '<OPTION VALUE=86>86</OPTION>';
if ($maat_upd == 98)
    $add .= '<OPTION SELECTED VALUE=98>98</OPTION>';
ELSE
    $add .= '<OPTION VALUE=98>98</OPTION>';
if ($maat_upd == 110)
    $add .= '<OPTION SELECTED VALUE=110>110</OPTION>';
ELSE
    $add .= '<OPTION VALUE=110>110</OPTION>';
if ($maat_upd == 122)
    $add .= '<OPTION SELECTED VALUE=122>122</OPTION>';
ELSE
    $add .= '<OPTION VALUE=122>122</OPTION>';
if ($maat_upd == 134)
    $add .= '<OPTION SELECTED VALUE=134>134</OPTION>';
ELSE
    $add .= '<OPTION VALUE=134>134</OPTION>';
if ($maat_upd == 146)
    $add .= '<OPTION SELECTED VALUE=146>146</OPTION>';
ELSE
    $add .= '<OPTION VALUE=146>146</OPTION>';
if ($maat_upd == 158)
    $add .= '<OPTION SELECTED VALUE=158>158</OPTION>';
ELSE
    $add .= '<OPTION VALUE=158>158</OPTION>';
if ($maat_upd == 170)
    $add .= '<OPTION SELECTED VALUE=170>170</OPTION>';
ELSE
    $add .= '<OPTION VALUE=170>170</OPTION>';

echo $add;

Ach ja, gelukkig is het al prehistorische code inmiddels..

[Anoniem: 37526]

Dat is wel erg eh, appart

PHP:

<?php 
$add = ''; 
$maten = array(50,62,74,86,98,110,122,134,146,158,170);

foreach ($maten as $maat){
    $add .= '<option value="'.$maat.'"';
    if ($maat == $maat_upd) $add .= ' selected="selected"';
    $add.= '>'.$maat.'</option>';
}

echo $add; 
?>

44 seconden werk

[Gomez12]

Anoniem: 37526 schreef op donderdag 12 april 2007 @ 19:51:
Dat is wel erg eh, appart

PHP:

<?php 
$add = ''; 
$maten = array(50,62,74,86,98,110,122,134,146,158,170);

foreach ($maten as $maat){
    $add .= '<option value="'.$maat.'"';
    if ($maat == $maat_upd) $add .= ' selected="selected"';
    $add.= '>'.$maat.'</option>';
}

echo $add; 
?>

44 seconden werk

Maar ja, misschien wordt hij per letter code betaald, dan kan ik me er nog iets bij voorstellen

[kenneth]

Anoniem: 37526 schreef op donderdag 12 april 2007 @ 19:51:
appart

apart


2 seconden werk

[Erkens]

Anoniem: 37526 schreef op donderdag 12 april 2007 @ 19:51:
Dat is wel erg eh, appart

PHP:

<?php 
$add = ''; 
$maten = array(50,62,74,86,98,110,122,134,146,158,170);

foreach ($maten as $maat){
    $add .= '<option value="'.$maat.'"';
    if ($maat == $maat_upd) $add .= ' selected="selected"';
    $add.= '>'.$maat.'</option>';
}

echo $add; 
?>

44 seconden werk

hmm, ik zou persoonlijk liever hier een sprintf gebruiken dan dat aan elkaar prakken van strings, ziet er imo minder "rommelig" uit:

PHP:

$add = ''; 
$maten = array(50,62,74,86,98,110,122,134,146,158,170);

foreach ($maten as $maat){
    $selected = ($maat==$maat_upd)?" selected":"";
    $add .= sprintf('<option value="%s"%s>%s</option>', $maat, $selected, $maat);
}

echo $add;

[MBV]

Ja maar dat snappen de meeste PHP-programmeurs niet

Laatst nog een discussie gehad over C-programmeurs die PHP hadden geleerd, en wat oude technieken in PHP toepasten. Riep er dus een: "Ja, in C is dat natuurlijk heel makkelijk om array in array in array te doen, maar dat moet je dan niet in PHP ook zo doen". Ehm, WTF? Laatst nog 3 uur mee bezig geweest om een simpele 2-dimensionale array in C elkaar te hacken

[writser]

Misschien iets offtopic, maar deze is ook wel leuk: http://worsethanfailure.c...all_it_Concatenation.aspx . Hoe verzint ie het .. Commentaar er onder is ook wel grappig.

code:

static public string PrependProtocol(string urlString) {
    string protocolString = "//:ptth";
    CharEnumerator charEnumerator = 
          protocolString.GetEnumerator();
    while (charEnumerator.MoveNext())
    {
        char padleftChar = charEnumerator.Current;
        urlString = urlString.PadLeft(urlString.Length + 1, padleftChar);
    }
    return urlString;
}

[MBV]

The real WTF is that he hardcoded the protocol. What if someone wants to use HTTPS?

[Vold]

Erkens schreef op donderdag 12 april 2007 @ 22:52:
hmm, ik zou persoonlijk liever hier een sprintf gebruiken dan dat aan elkaar prakken van strings, ziet er imo minder "rommelig" uit:

Ik ga dit topic eens helemaal doorlezen, ik leer een hele hoop bij. Ik had al zo'n vermoeden dat dit makkelijker kon:

PHP:

  <option value="2007"<?php if($_POST['jaar'] == '2007') { echo 'selected'; } ?>>2007</option>
  <option value="2008"<?php if($_POST['jaar'] == '2008') { echo 'selected'; } ?>>2008</option>
  <option value="2009"<?php if($_POST['jaar'] == '2009') { echo 'selected'; } ?>>2009</option>
  <option value="2010"<?php if($_POST['jaar'] == '2010') { echo 'selected'; } ?>>2010</option>
  <option value="2011"<?php if($_POST['jaar'] == '2011') { echo 'selected'; } ?>>2011</option>
  <option value="2012"<?php if($_POST['jaar'] == '2012') { echo 'selected'; } ?>>2012</option>

Nu heb ik het zo gedaan:

PHP:

  <?php 
for ($i = 2007; $i <= 2020; $i++) {
    $selected = ($i==$_POST['jaar'])?" selected":"";
    $jaar .= sprintf('<option value="%s"%s>%s</option>', $i, $selected, $i);
}
echo $jaar; 
  ?>

Dat scheelt eens veel werk! Moet wel zeggen dat ik het als leek wel erg waardeer als jullie ook de "goede/beste" methode erbij posten.

[Anoniem: 26306]

Zo zou ik het dan doen.

PHP:

<?php 
   for ($i = 2007; $i <= 2020; $i++) {
      printf ( '<option value="%1$u"%2$s>%1$u</option>',
         $i,
         $i == $_POST [ 'jaar' ] ? ' selected' : ''
      );
   }
?>

Maar op een gegeven moment is het niet meer "beter" maar gewoon "anders" en dan is het afhankelijk van smaak.

[soulrider]

Vold schreef op zaterdag 14 april 2007 @ 16:39:
[...]


Dat scheelt eens veel werk! Moet wel zeggen dat ik het als leek wel erg waardeer als jullie ook de "goede/beste" methode erbij posten.

zeg maar "betere" methode

over beste methode zijn er soms discussie's
maar idd dankzij dit topic kunde leren van anderen hun fouten

en met een beschaamd gezicht je oude code zitten bekijken ....

[AtleX]

HTML:

selected="selected"

[edit]
Of mag alleen "selected" ook in HTML 4.01? Ik weet het eerlijk gezegd niet meer.

[ Voor 72% gewijzigd door AtleX op 14-04-2007 16:51 ]

[Robtimus]

AtleX schreef op zaterdag 14 april 2007 @ 16:50:

HTML:

selected="selected"

[edit]
Of mag alleen "selected" ook in HTML 4.01? Ik weet het eerlijk gezegd niet meer.

In HTML mag dit, in XHTML moet het echter met waarde zijn.

[mithras]

AtleX schreef op zaterdag 14 april 2007 @ 16:50:

HTML:

selected="selected"

[edit]
Of mag alleen "selected" ook in HTML 4.01? Ik weet het eerlijk gezegd niet meer.

http://www.w3.org/TR/html4/interact/forms.html#adef-selected UTFS!

[Vold]

Anoniem: 26306 schreef op zaterdag 14 april 2007 @ 16:47:
Zo zou ik het dan doen.
Maar op een gegeven moment is het niet meer "beter" maar gewoon "anders" en dan is het afhankelijk van smaak.

Ja ik had al moeite met de woordenkeus daarbij, vandaar de aanhalingstekens.

Ik heb net het hele topic doorgelezen en ik kon in bijna alle php gerelateerde voorbeelden de fout(en) vinden! Sinds ik weer een phpboek heb gekocht merk ik toch wel dat mijn kennis weer een stuk beter geworden is. Het maken van webtutorials werkt niet zo goed als een lekker dik boek.

offtopic:
edit: ik snap nu hoe jou voorbeeld (net) iets efficienter weer is, moet wel zeggen dat het wel wat ten koste gaat van de leesbaarheid. (maar dat komt misschien omdat ik deze manier van outputten nooit eerder heb gebruikt.. )

[ Voor 17% gewijzigd door Vold op 14-04-2007 17:53 ]

[Woy]

Vold schreef op zaterdag 14 april 2007 @ 17:45:
[...]

offtopic:
edit: ik snap nu hoe jou voorbeeld (net) iets efficienter weer is, moet wel zeggen dat het wel wat ten koste gaat van de leesbaarheid. (maar dat komt misschien omdat ik deze manier van outputten nooit eerder heb gebruikt.. )

In de meeste gevallen is leesbaarheid belangrijker als pure performance ( in 99,99 % van de gevallen valt er meer te optimaliseren door een beter algroritme te bedenken dan door te muggeziften over een paar simpele instructies ). In dit geval zal het zo goed als niks uithalen op welke manier je het doet. Dus kan je beter voor de manier gaan die jij het best leesbaar vindt.
Welke van de 2 manieren dat is kan natuurlijk per persoon verschillen.

[Erkens]

Vold schreef op zaterdag 14 april 2007 @ 17:45:
edit: ik snap nu hoe jou voorbeeld (net) iets efficienter weer is, moet wel zeggen dat het wel wat ten koste gaat van de leesbaarheid. (maar dat komt misschien omdat ik deze manier van outputten nooit eerder heb gebruikt.. )

De leesbaarheid van zijn code is wat te vergroten door een betere indenting, verder moet worden opgemerkt dat het iets anders doet dan jouw code.
Jij slaat alles eerst op een een (al reeds gedefinieerde?) variabele en uiteindelijk "echo" je het, terwijl Cheatah rechtstreeks naar de output print, dus in jouw geval had er nog meer geprint kunnen worden (en zelfs een mooie notice over een undefined var ) en achteraf kan je indien gewenst nogmaals diezelfde code in de output gooien, daar waar dat bij Cheatah's code dus niet mogelijk is

[Serpie]

Ik vind het niet perse slechte code, maar het volgende is wel erg vaag, kan iemand mij uitleggen wat de logica is van het volgende?

Visual Basic .NET:

    For teller As Integer = 0 To 10
      Dim waarde As Integer
      waarde += 1

      Debug.Write(waarde)
    Next

Ik declareer dus de variabele in de for loop, en ik zou hier als output allemaal enen verwachten, de output is echter "12345678910".

Maak ik er het volgende van, dan geeft hij wel het gewenste (verwachte) resultaat.

Visual Basic .NET:

    For teller As Integer = 0 To 10
      Dim waarde As Integer = 0
      waarde += 1

      Debug.Write(waarde)
    Next

Ik heb echter de variabele buiten de loop gezet en zelf steeds gereset, dit leek me nog wat beter. Maar het blijft vaag.

[ Voor 8% gewijzigd door Serpie op 16-04-2007 14:40 ]

[.oisyn]

Het is wel slechte code, je initialiseert je variabele niet waardoor hij in principe elke waarde kan hebben (de compiler genereert code dat ruimte alloceert op de stack, maar initialiseert dat niet, waardoor toevalligerwijs in dit geval de waarde van de vorige iteratie er nog in stond)

[Serpie]

.oisyn schreef op maandag 16 april 2007 @ 14:48:
Het is wel slechte code, je initialiseert je variabele niet waardoor hij in principe elke waarde kan hebben (de compiler genereert code dat ruimte alloceert op de stack, maar initialiseert dat niet, waardoor toevalligerwijs in dit geval de waarde van de vorige iteratie er nog in stond)

Hmm toch weer wat geleerd, dit is toch niet zo 1-2-3 terug te vinden in de MSDN, en bij klasse variabelen geeft code analysis een melding dat het performanter is om de initializer weg te laten..

Vandaar de verwarring, maar ik vond het volgende nu in de MSDN:

Even if the scope of a variable is limited to a block, its lifetime is still that of the entire procedure. If you enter the block more than once during the procedure, each block variable retains its previous value. To avoid unexpected results in such a case, it is wise to initialize block variables at the beginning of the block.

Dit is dus precies deze situatie.

[brama]

Die variabele is, zonder expliciet te initialiseren, altijd 0? Iets wat in andere talen zoals C of Java zeker niet zo is.

[NetForce1]

brama schreef op maandag 16 april 2007 @ 15:43:
Die variabele is, zonder expliciet te initialiseren, altijd 0? Iets wat in andere talen zoals C of Java zeker niet zo is.

Dat is in Java juist wel zo.

Java:

static int myInt;
public class Test {
  public static void main(String[] args) {
    System.out.println(myInt);
  }
}

dit print 0, maar de geposte vb code overzetten naar Java gaat niet werken, dan krijg je een compile error ('The local variable myInt may not have been initialized').

[brama]

NetForce1 schreef op maandag 16 april 2007 @ 15:53:
[...]

Dat is in Java juist wel zo.

Java:

static int myInt;
public class Test {
  public static void main(String[] args) {
    System.out.println(myInt);
  }
}

dit print 0, maar de geposte vb code overzetten naar Java gaat niet werken, dan krijg je een compile error ('The local variable myInt may not have been initialized').

In java zijn alleen variabelen die op de stack gezet worden (lokale variabelen) niet voorzien van een default waarde ja.

[.oisyn]

Ook de stack variabelen zijn voorzien van een default waarde (0 danwel null) hoor. Ook in .Net trouwens. Als dat niet het geval was dan was de veiligheid van de VM in het geding (denk bevoorbeeld aan gevoelige data die uit een functie lekt door ongeinitialiseerde variabelen uit te lezen, of referenties naar objecten die helemaal niet bestaan)

[Michali]

Je krijgt dan ook een compile error als je een lokale variabel niet initialiseert in Java.

[MTWZZ]

.oisyn schreef op dinsdag 17 april 2007 @ 00:18:
Ook de stack variabelen zijn voorzien van een default waarde (0 danwel null) hoor. Ook in .Net trouwens. Als dat niet het geval was dan was de veiligheid van de VM in het geding (denk bevoorbeeld aan gevoelige data die uit een functie lekt door ongeinitialiseerde variabelen uit te lezen, of referenties naar objecten die helemaal niet bestaan)

Had Alarmnummer hier niet een topic over gemaakt icm concurrency?

[Salandur]

Michali schreef op dinsdag 17 april 2007 @ 08:33:
Je krijgt dan ook een compile error als je een lokale variabel niet initialiseert in Java.

meestal is het een warning en die krijg je alleen bij objecten, niet bij de zgn primitives

[NetForce1]

Salandur schreef op dinsdag 17 april 2007 @ 09:15:
[...]

meestal is het een warning en die krijg je alleen bij objecten, niet bij de zgn primitives

Misschien eens tijd om het uit te proberen dan? Ik krijg nl toch echt een prachtige error, zoals ik een paar posts hierboven ook al aangaf.

[Salandur]

NetForce1 schreef op dinsdag 17 april 2007 @ 09:32:
[...]

Misschien eens tijd om het uit te proberen dan? Ik krijg nl toch echt een prachtige error, zoals ik een paar posts hierboven ook al aangaf.

ik krijg in beide gevallen inderdaad een error indien ze binnen een methode (dus op de stack) gecreerd worden. maar het zowiso een goed gebruik om variabelen altijd te initialiseren.

[.oisyn]

Michali schreef op dinsdag 17 april 2007 @ 08:33:
Je krijgt dan ook een compile error als je een lokale variabel niet initialiseert in Java.

Met de standaard Java compiler ja. Dat is natuurlijk niet de enige manier om bytecode te genereren, dus een compiler error zorgt niet dat de boel veilig blijft

[brama]

.oisyn schreef op dinsdag 17 april 2007 @ 12:09:
[...]


Met de standaard Java compiler ja. Dat is natuurlijk niet de enige manier om bytecode te genereren, dus een compiler error zorgt niet dat de boel veilig blijft

In de categorie 'jezelf in bochten wringen om je onder een argument uit te lullen'

Stack variabelen worden niet geinitialiseerd, en ze zullen moeten worden geinitialiseerd voor je ze mag gebruiken. Durf zelfs te wedden dat elke compiler hier aan moet voldoen, en anders mag het geen java heten (mag sowieso al niet waarschijnlijk, althans niet certified).

[.oisyn]

brama schreef op dinsdag 17 april 2007 @ 14:44:

In de categorie 'jezelf in bochten wringen om je onder een argument uit te lullen'

Geenszins, het zat zelfs al in mijn achterhoofd toen ik mijn eerste post tikte, omdat ik wel reacties had verwacht waarin werd verklaard dat de compiler een error zou geven. Mijn post ging over de veiligheid van de VM, de compiler kan dat niet garanderen, ik hoop dat je dat zelf ook wel snapt.

Stack variabelen worden niet geinitialiseerd, en ze zullen moeten worden geinitialiseerd voor je ze mag gebruiken. Durf zelfs te wedden dat elke compiler hier aan moet voldoen, en anders mag het geen java heten (mag sowieso al niet waarschijnlijk, althans niet certified).

Leuk, maar de eindgebruiker heeft geen controle over de gebruikte compiler van een vendor. Als ik jou een applicatie verschaf dan geef ik de bytecode, maar jij weet niet of ik wel een certified Java^TM compiler heb gebruikt om die applicatie mee te compilen. Jij hebt slechts de bytecode, en de vm moet die veilig kunnen executen. De VM zal de variabelen (of iig de stack waar die variabelen op terecht komen) dus zero-initializen om veiligheid te kunnen garanderen. Vziw geeft de JIT compiler niet @ runtime een error als blijkt dat een var niet door de bytecode geinitialiseerd wordt.

.edit: bliep, dat is niet mogelijk. Als je een local var niet eerst schrijft zegt ie dus wel dat ie nog ongeinitialiseerd is, en krijg je een java.lang.VerifyError

code:

.class public HelloWorld
.super java/lang/Object

.method public static main([Ljava/lang/String;)V
   .limit stack 2
   .limit locals 2
   
   getstatic java/lang/System/out Ljava/io/PrintStream;
   iload 1
   invokevirtual java/io/PrintStream/println(I)V

   return
.end method

Exception in thread "main" java.lang.VerifyError: (class: HelloWorld, method: main signature: ([Ljava/lang/String;)V) Accessing value from uninitialized register 1

De lokale variabelen krijgen ook pas type-informatie mee als je ze schrijft. Als ik 'iload 0' had gedaan (dus het String[] argument naar de main() functie), zegt ie dat die var het verkeerde type heeft.

[ Voor 28% gewijzigd door .oisyn op 17-04-2007 16:12 ]

[brama]

.oisyn schreef op dinsdag 17 april 2007 @ 14:59:
Leuk, maar de eindgebruiker heeft geen controle over de gebruikte compiler van een vendor. Als ik jou een applicatie verschaf dan geef ik de bytecode, maar jij weet niet of ik wel een certified Java^TM compiler heb gebruikt om die applicatie mee te compilen. Jij hebt slechts de bytecode, en de vm moet die veilig kunnen executen. De VM zal de variabelen (of iig de stack waar die variabelen op terecht komen) dus zero-initializen om veiligheid te kunnen garanderen. Vziw geeft de JIT compiler niet @ runtime een error als blijkt dat een var niet door de bytecode geinitialiseerd wordt.

Ok, je hebt je eigen argument om zeep geholpen met je test, niet dat ik dat vantevoren wist hoor Maar los van het feit of het al dan niet zonder runtime error zou draaien, lijkt het mij logisch dat je van een vendor vereist dat je code krijgt die Certified Java(TM) is (en dus ook door die compiler gebouwd werd). En zelfs al doe je dat niet, dan verwacht ik dat ze in ieder geval werkende en geteste code opleveren, en erbij vertellen op welk platform het getest is.

Ben wel benieuwd of de VM nu toch daadwerkelijk gaat zero-initialisen, lijkt me een overbodige zaak aangezien je er toch niet wegkomt.