[alg] Slechtste programmeervoorbeelden deel 4

[.oisyn]

Nuttig

[Haan]

Beter 1x teveel dan 1x te weinig

[g4wx3]

Ha tables...
Toen ik net begon met html en javascript wou ik zoveel mogelijk verschillende html tags gebruiken om het aan te leren, en te oefenen. Liet ik het zien aan iemand anders, en die meteen: Ach javascript is voor mietjes je php leren, en je moet zeker leren werken met tables om je content te positioneren. Ok geen javscript meer, en met tables en een iframe, wat resulteerde in een mooie layout. Weer laten zien, toen was ie wel verbaasd, dacht dat ik met flash had ineen gezet. Print voorbeeld was wel helemaal fout. (tijden van ie5). Ohja, en outerglow en dergelijke filters, die ik later nooit meer heb gebruikt.

Met de aanbreek van een nieuwe internet-desing-golf, ben ik meegegaan, en heb ik nu tables achterwegengelaten. In het begin was het streven naar een zo flexibel mogelijk design, en erger: zelfs voor tabel data gebruikte ik geneste div. En alles uiteraard in XHTML.
Ondertussen ben ik daar ook weer vanaf gestapt. Ik heb nu een design, hardcoded in php, bestaande uit heel wat geneste DIV (gemiddeld niveau 3-4). Aanpassingen kan ik wel makkelijk maken, maar dan moet ik in mijn php-bron bestanden zitten.

De dag dat ik echt flexibel en modulair ga zijn, dan leer ik me eerst een framework aan. ook ben ik teruggestapt naar html 4.1 trans, xhtml geeft veel te veel crossbrowser inconsistenties.

Maar als je een andere layout wilt, dan kun je je meestal toch niet beperken tot een paar css aanpassingen, vandaar dat ik die filosofie niet volg. Ja wat zen garden presteerd is wel uniek

[ Voor 6% gewijzigd door g4wx3 op 30-01-2009 11:57 ]

[Verwijderd]

Daarnaast lijkt me

PHP:

if($type = 'langpack'){

ipv

PHP:

if($type == 'langpack'){

ook niet helemaal de bedoeling.

[ Voor 21% gewijzigd door Verwijderd op 30-01-2009 11:55 ]

[Config]

En vergeet de unreachable code niet.

[.oisyn]

g4wx3 schreef op vrijdag 30 januari 2009 @ 11:55:
Maar als je een andere layout wilt, dan kun je je meestal toch niet beperken tot een paar css aanpassingen, vandaar dat ik die filosofie niet volg. Ja wat zen garden presteerd is wel uniek

CSS is ook helemaal niet bedoeld voor meerdere layouts. Layout hangt namelijk ook gewoon af van je flow. Met CSS kun je de flow niet aanpassen.

Ik vind het overigens een beetje dom dat je de HTML in je PHP hebt zitten hardcoden. Ik doe dat zelf nooit, terwijl ik ook nooit gebruik maak van allerlei frameworks. PHP is namelijk een template parser pur sang - gewoon van tevoren je data in variabelen zetten, en dan een php filetje includen die die data presenteert als html. Dan kun je de layout ook heel gemakkelijk aanpassen.

[st0p]

Denk dat dit stukje code wel genoeg zegt over de algemene staat van de site die ik mag onderhouden:

PHP:

$smarty->sql =& $sql;

[Woy]

Config schreef op vrijdag 30 januari 2009 @ 11:34:

PHP:

                if($can_install){
                    // handle manifest.php
                    $target_manifest = remove_file_extension( $file ) . '-manifest.php';
                    if($type = 'langpack'){
                        $_REQUEST['manifest'] = $target_manifest;
                        $_REQUEST['zipFile'] = $file;
                        commitLanguagePack();
                        continue;
                    }
                    if($type = 'langpack'){
                        $_REQUEST['manifest'] = $target_manifest;
                        $_REQUEST['zipFile'] = $file;
                        commitLanguagePack();
                        continue;
                    }
                    include($target_manifest);
//even more code

Ik zie het nut ook niet zo in van dingen in de $_REQUEST array zetten. ( Of ieder geval zou ik het niet doen )

[Zoijar]

.oisyn schreef op vrijdag 30 januari 2009 @ 17:50:
CSS is ook helemaal niet bedoeld voor meerdere layouts. Layout hangt namelijk ook gewoon af van je flow. Met CSS kun je de flow niet aanpassen.

Ik vind het overigens een beetje dom dat je de HTML in je PHP hebt zitten hardcoden. Ik doe dat zelf nooit, terwijl ik ook nooit gebruik maak van allerlei frameworks. PHP is namelijk een template parser pur sang - gewoon van tevoren je data in variabelen zetten, en dan een php filetje includen die die data presenteert als html. Dan kun je de layout ook heel gemakkelijk aanpassen.

Ik doe het ook volledig met CSS. Enige HTML output is gestructureerde content in de vorm van div's en p's etc. Wat dat betreft is het net als XML/XSLT, wat het natuurlijk ook min of meer is in de vorm XHTML/CSS. Je kan makkelijk een compleet andere layout opzetten door alleen de .css file te herschrijven. Als je een nieuw "type" content toevoegd, dan moet je uiteraard de presentatie van die content beschrijven in de css.

[!null]

@g4wx3, daar hebben we templates voor. Gewoon je HTML in een template (bijvoorbeeld met Smarty), en je PHP apart. In je HTML verwijs je dan weer naar je CSS. Mooi gescheiden houden allemaal.

Frameworks heb ik ook nog niet veel mee gedaan. Het is me ook niet duidelijk hoever sommige frameworks gaan. Is het een framework waarbinnen ik moet werken, of waarmee ik moet werken. Een library met wat generieke functies is erg makkelijk geschreven (even een alleskunnend database object daargelaten), maar het is natuurlijk zonde om het wiel opnieuw uit te vinden. En je kan profiteren van dingen als searchengine-friendly urls etc.
Wanneer een nieuw project zich aandient zal ik de keuze opnieuw moeten bekijken. (ik doe dit soort werk niet fulltime)

[.oisyn]

Zoijar schreef op maandag 02 februari 2009 @ 16:04:
[...]

Ik doe het ook volledig met CSS. Enige HTML output is gestructureerde content in de vorm van div's en p's etc. Wat dat betreft is het net als XML/XSLT, wat het natuurlijk ook min of meer is in de vorm XHTML/CSS.

Nee, XML is puur content zonder voorgedefinieerde volgorde. (X)HTML heeft een flow dat vast zit in het document. Als je een HTML doc hebt waar data in staat, kun je niet mbv CSS ervoor kiezen om die data horizontaal te rangschikken ipv verticaal zoals door de flow gedefinieerd wordt. Ook met floats kom je vaak in de problemen als je net iets anders wilt dan de manier waarvoor de doc in eerste instantie is opgezet. Met CSS bepaal je slechts het uiterlijk van de bestaande elementen. Niet de layout zelf. Je kúnt wel layoutwijzingen doen, maar ik vind dat meer CSS hacks dan daadwerkelijk mooie oplossingen. Dan kun je beter denken aan oplossingen als XML/XSLT of template systems.

[Tanuki]

st0p schreef op maandag 02 februari 2009 @ 15:26:
Denk dat dit stukje code wel genoeg zegt over de algemene staat van de site die ik mag onderhouden:

PHP:

$smarty->sql =& $sql;

Wat is hier mis mee? Je vult de 'sql' property met een waarde, dat is toch niks raars?
Waarschijnlijk wordt de gettext plugin of zo gebruikt binnen Smarty (ik neem aan dat dat een instantie is van Smarty, de template parser) om teksten uit de database te halen.

Ik zie dus niet direct wat hier zo erg aan is.

rwb schreef op maandag 02 februari 2009 @ 15:32:
[...]

Ik zie het nut ook niet zo in van dingen in de $_REQUEST array zetten. ( Of ieder geval zou ik het niet doen )

Het script dat hij include haalt z'n data uit $_REQUEST. Waarschijnlijk zijn die te includen scripts ook voor normaal gebruik (dus gewoon bla-manifest.php?zipFile=x&manifest=y aanroepen).

[ValHallASW]

Over tables vs css gesproken: Ron Garret had daar nog een mooie rant over. Vooral zijn eerste followup is verfrissend om te lezen. De comments zijn vooral grappig: een hele hoop css-fanboys die roepen dat we in 2009 leven en niet in 1997, maar ook een hoop mensen die dezelfde ergernis hebben. Daartussen staat gelukkig ook nog een paar interessante en onderbouwde comments

Nuja, give up and use tables

[ Voor 7% gewijzigd door ValHallASW op 07-02-2009 02:27 ]

[MatHack]

Wij zijn ongeveer een half jaar geleden over gegaan van VSS naar TFS (Team Foundation Server, onderdeel van MS Team System). Persoonlijk vind ik het een grote verbetering. Ik kan geen vergelijking doen met SVN, aangezien ik daar nog nooit mee heb gewerkt.

Shelving is het opslaan van je wijzigingen, maar niet het inchecken ervan.

on-topic:

Wat ik nogal vaak terug vindt in code van oude projecten:

C#:

try
{ ... }
catch (Exception ex)
{
    throw new Exception(ex.Message);
}

Nogal fijn dat je daarna niet meer kan zien welk type exception de originele exception was (en de andere dingen ook, zoals stacktrace).

[ Voor 32% gewijzigd door MatHack op 08-02-2009 19:12 ]

[Sebazzz]

Klopt. Je kan dan ook het beste exceptions maar laten gaan of loggen en rethrowen.

C#:

try {
    File.Open("blaat.txt");
} catch (Exception ex) {
    Log.Error("Het ging eventjes niet goed 8)", ex);
    
    throw; // anders verschuift de stacktrace (vergelijk met throw ex;)
}

[HawVer]

@MatHack en Sebazzz, volgende artikel is zeker het lezen waard. Kort komt het er op neer waarom niet catchen op Exception niveau en hoe om te gaan met exception handling. Ik heb er veel van geleerd en zorgt er nu voor dat ik beter nadenk over het gebruik van excepties.

http://blogs.msdn.com/fxc..._Nick-Guerrera_5D00_.aspx

[MatHack]

HawVer schreef op zondag 08 februari 2009 @ 23:02:
@MatHack en Sebazzz, volgende artikel is zeker het lezen waard. Kort komt het er op neer waarom niet catchen op Exception niveau en hoe om te gaan met exception handling. Ik heb er veel van geleerd en zorgt er nu voor dat ik beter nadenk over het gebruik van excepties.

http://blogs.msdn.com/fxc..._Nick-Guerrera_5D00_.aspx

Ja, ik weet prima dat je dat niet moet doen, daarom kaartte ik het ook aan in dit topic

[Creepy]

Even geduld Even wat afsplitsen

Zow... even wat posts over version control e.d. afgesplitst naar [alg] Ervaringen met Source Contol systemen.. Mocht ik nog wat vergeten zijn let me know

[ Voor 74% gewijzigd door Creepy op 10-02-2009 12:07 ]

[Config]

PHP:

    if(!isset($_REQUEST['silent'])){
        $_REQUEST['silent'] = true;
    }
    else if(isset($_REQUEST['silent']) && $_REQUEST['silent'] != true){
        $_REQUEST['silent'] = true;
    }

Waarheidstabel:

FALSE => true
TRUE => true
* => true

[ Voor 13% gewijzigd door Config op 10-02-2009 17:35 ]

[Kettrick]

Config schreef op dinsdag 10 februari 2009 @ 17:34:

PHP:

    if(!isset($_REQUEST['silent'])){
        $_REQUEST['silent'] = true;
    }
    else if(isset($_REQUEST['silent']) && $_REQUEST['silent'] != true){
        $_REQUEST['silent'] = true;
    }

Waarheidstabel:

FALSE => true
TRUE => true
* => true

Dat kan korter

[Jaap-Jan]

Wat een gedoe om gewoon

PHP:

$_REQUEST['silent'] = true;

te doen.

[Amras]

Config schreef op dinsdag 10 februari 2009 @ 17:34:

PHP:

    if(!isset($_REQUEST['silent'])){
        $_REQUEST['silent'] = true;
    }
    else if(isset($_REQUEST['silent']) && $_REQUEST['silent'] != true){
        $_REQUEST['silent'] = true;
    }

Waarheidstabel:

FALSE => true
TRUE => true
* => true

Ik zie hier nog weleens afschuwelijke logische constructies langskomen, maar deze slaat alles. Bedankt! Volgende keer dat ik iets zie, weet ik dat het altijd nog erger kan.

[MBV]

edit:
nvm

[ Voor 97% gewijzigd door MBV op 10-02-2009 18:03 ]

[.oisyn]

Jaap-Jan schreef op dinsdag 10 februari 2009 @ 17:36:
Wat een gedoe om gewoon

PHP:

$_REQUEST['silent'] = true;

te doen.

Niet helemaal. Als $_REQUEST['silent'] namelijk een niet-lege string is of een int/float ongelijk aan 0, dan houdt ie die waarde . In jouw oplossing wordt ie echter altijd true.

[CoolGamer]

.oisyn schreef op dinsdag 10 februari 2009 @ 18:18:
[...]


Niet helemaal. Als $_REQUEST['silent'] namelijk een niet-lege string is of een int/float ongelijk aan 0, dan houdt ie die waarde . In jouw oplossing wordt ie echter altijd true.

Blijft een omslachtige manier om dit te schrijven:

PHP:

if (!isset($_REQUEST['silent']) || !$_REQUEST['silent']) {
    $_REQUEST['silent'] = true;
}

Al denk ik dat de schrijver van de oorspronkelijke code de bedoeling had om de waarde in true te veranderen wanneer de waarde nog niet de waarde true had en geen rekening had gehouden met deze uitzondering die jij noemt. Dus Jaap-Jan's oplossing had waarschijnlijk dus ook voldaan. Maarja, dat krijg je met talen die niet strongly-typed zijn en het type van een variabele niet controleert.

[Woy]

Config schreef op dinsdag 10 februari 2009 @ 17:34:

PHP:

    if(!isset($_REQUEST['silent'])){
        $_REQUEST['silent'] = true;
    }
    else if(isset($_REQUEST['silent']) && $_REQUEST['silent'] != true){
        $_REQUEST['silent'] = true;
    }

Waarheidstabel:

FALSE => true
TRUE => true
* => true

Het moet denk ook wel een multithreaded omgeving zijn, anders controleer je ook niet nog een keer in de else of $_REQUEST['silent'] toch niet opeens stiekem gezet is

[Gomez12]

rwb schreef op dinsdag 10 februari 2009 @ 20:46:
[...]

Het moet denk ook wel een multithreaded omgeving zijn, anders controleer je ook niet nog een keer in de else of $_REQUEST['silent'] toch niet opeens stiekem gezet is

Ik wil geloof ik niet weten hoeveel recursieve else's jij gebruikt in een multithreaded app. Dat gaat denk ik richting oneindig ofzo?

Want volgens jouw theorie kan tussen de check en de daadwerkelijke uitvoering van de code nog steeds de status veranderen dus nog maar eens een keertje controleren en nog een keer en nog een keer....

[.oisyn]

Ik weet niet of je weleens lockless code hebt geschreven, of je eigen lock primitives, maar dan is dat idd common practice. En dan natuurlijk in een loop, niet een oneindige nesting van ifs.

Verder denk ik dat je de reactie van rwb te serieus neemt

[Zoijar]

double-checked locking (considered harmful) Ik wil toch nog steeds een keer een paper publiceren met een "considered harmful" titel....

[ Voor 50% gewijzigd door Zoijar op 11-02-2009 00:02 ]

[Jaap-Jan]

Zoijar schreef op woensdag 11 februari 2009 @ 00:02:
double-checked locking (considered harmful) Ik wil toch nog steeds een keer een paper publiceren met een "considered harmful" titel....

Reageer je nu op .oisyn? Want ik denk dat 'ie geen double-checked locking bedoeld, maar een spinlock.

[Woy]

Het was inderdaar niet al te serieus bedoeld ( vandaar de ), maar in de code waarin ik nu bezig ben staan toch wel zulke dingen.

C:

// Wait while SPI transfer is in progress
while (!(*SPI_STATUS & 0x00000001)) ;

Inderdaad niet met geneste if's want dat is nogal zinloos als je niet iets anders doet tussen de if/else

[ Voor 3% gewijzigd door Woy op 11-02-2009 09:55 ]

[Zoijar]

Jaap-Jan schreef op woensdag 11 februari 2009 @ 00:09:
[...]
Reageer je nu op .oisyn? Want ik denk dat 'ie geen double-checked locking bedoeld, maar een spinlock.

Nee, meer in het algemeen op twee keer exact hetzelfde checken achter elkaar

[.oisyn]

Zoijar schreef op woensdag 11 februari 2009 @ 00:02:
double-checked locking (considered harmful) Ik wil toch nog steeds een keer een paper publiceren met een "considered harmful" titel....

Ik heb het niet over double checked locking. Ik heb het over lock-free code. Zoals bijvoorbeeld het pushen van een object op een stack / linked list mbv test-and-set/compare-and-swap operaties.

[ Voor 3% gewijzigd door .oisyn op 11-02-2009 10:44 ]

[flux_w42]

Iemand heeft blijkbaar het nut van short notations niet helemaal door

Java: counter.java

int counter = 0;

//... heel veel spaghetti code

counter = ++counter;

//nog meer spaghetti code ...

[Haan]

In ieder geval werkt het wel zonder bijwerkingen

[Woy]

flux_w42 schreef op vrijdag 13 februari 2009 @ 13:55:
Iemand heeft blijkbaar het nut van short notations niet helemaal door

Java: counter.java

int counter = 0;

//... heel veel spaghetti code

counter = ++counter;

//nog meer spaghetti code ...

Het zou pas mooi zijn als het er zo stond

Java: counter.java

int counter = 0;

//... heel veel spaghetti code

counter = counter++;

//nog meer spaghetti code ...

[Quincy5]

flux_w42 schreef op vrijdag 13 februari 2009 @ 13:55:
Iemand heeft blijkbaar het nut van short notations niet helemaal door

Java: counter.java

int counter = 0;

//... heel veel spaghetti code

counter = ++counter;

//nog meer spaghetti code ...

Wat is hier nou precies mis mee? Had hij counter++ moeten gebruiken of mis ik iets volledig

[.oisyn]

Woy schreef op vrijdag 13 februari 2009 @ 14:11:
[...]

Het zou pas mooi zijn als het er zo stond

Java: counter.java

int counter = 0;

//... heel veel spaghetti code

counter = counter++;

//nog meer spaghetti code ...

Hoe werkt dat in Java? In C++ ben je in dit geval overgeleverd aan de keuzes van de compiler .

[kenneth]

Quincy5 schreef op vrijdag 13 februari 2009 @ 14:12:
[...]

Wat is hier nou precies mis mee? Had hij counter++ moeten gebruiken of mis ik iets volledig

Ja:

Java:

++counter;

of

Java:

counter += 2;

[ Voor 66% gewijzigd door kenneth op 13-02-2009 14:15 ]

[Phyxion]

Quincy5 schreef op vrijdag 13 februari 2009 @ 14:12:
[...]

Wat is hier nou precies mis mee? Had hij counter++ moeten gebruiken of mis ik iets volledig

Stel counter = 10;
++counter verhoogt counter voor uitvoering al naar 11;
counter++ verhoogt counter na uitvoering naar 11;
In dit geval, counter = ++counter, dan is "counter =" compleet nutteloos omdat het al 11 is. Dit komt op hetzelfde neer als counter = counter.

[Quincy5]

@kenneth:
Snap het nog steeds niet helemaal, maar in C is counter++ equivalent aan counter += 1. Is dit in Java anders of is dit een foutje?

Edit: Stom dat ik daar zo overheen kijk! Gebruik zelf de constructie ook vaak zat.

[ Voor 24% gewijzigd door Quincy5 op 13-02-2009 14:21 . Reden: phyxion's uitleg ]

[Woy]

.oisyn schreef op vrijdag 13 februari 2009 @ 14:15:
[...]


Hoe werkt dat in Java? In C++ ben je in dit geval overgeleverd aan de keuzes van de compiler .

Ik weet niet precies hoe het gedefineerd is eigenlijk. Nou ik er over nadenk is het inderdaad nog gekker dan dat ik bedoelde

[ Voor 20% gewijzigd door Woy op 13-02-2009 14:36 ]

[momania]

.oisyn schreef op vrijdag 13 februari 2009 @ 14:15:
[...]


Hoe werkt dat in Java? In C++ ben je in dit geval overgeleverd aan de keuzes van de compiler .

int counter = 1;
counter = counter++;

counter is nu nog steeds 1, java doet eerst counter assignment, dan pas increment

int counter = 1;
counter = ++counter;

counter is nu 2 omdat de increment nu voor de assignment gebeurt.

In beide gevallen is het gewoon domme code, want doe je counter++ of ++ counter zonder assignments ergens zit je altijd safe

[.oisyn]

momania schreef op vrijdag 13 februari 2009 @ 14:23:
[...]


int counter = 1;
counter = counter++;

counter is nu nog steeds 1, java doet eerst counter assignment, dan pas increment

Dit is een tegenspraak. Als ie aan het eind pas de increment doet dan is het 2. Ik denk dat je bedoelt dat hij eerst de increment doet, en vervolgens de oude waarde aan counter assignt (wat de increment weer teniet doet). Het is dan trouwens wel zo dat een andere thread eventueel tijdelijk een 2 kan zien

In C en C++ is alleen gedefinieerd dat de bijwerking van de post-increment iig plaats vindt vóór het volgende sequence point. Dat sequence-point is hier het einde van de statement, dus je weet niet of het nou voor of na de assignment is.

[Woy]

De C# compiler maakt er de volgende IL van

code:

ldsfld     int32 IncrementTest.Program::counter
dup
ldc.i4.1
add
stsfld     int32 IncrementTest.Program::counter
stsfld     int32 IncrementTest.Program::counter

Dus dan heb je idd een korte periode ( tussen regel 5 en 6 ) waarin counter 2 is

[ Voor 3% gewijzigd door Woy op 13-02-2009 14:58 ]

[Jaap-Jan]

code:

Preincrement:
   0:   iconst_0
   1:   istore_1
   2:   iinc    1, 1
   5:   iload_1
   6:   istore_1

Postincrement:
   0:   iconst_0
   1:   istore_1
   2:   iload_1
   3:   iinc    1, 1
   6:   istore_1

Bij Java dus niet anders. Bij postincrement is counter tussen de iinc en de istore_1 even 1.

[Snake]

Java:

                return key.startsWith(prefix + ".") ||
                       key.startsWith(prefix) || 
                       key.equals(prefix);

Mmmm alleen de eerste regel was goed geweest denk ik

key & prefix zijn beide String

[ Voor 7% gewijzigd door Snake op 13-02-2009 18:43 ]

[prototype]

Snake schreef op vrijdag 13 februari 2009 @ 18:42:

Java:

                return key.startsWith(prefix + ".") ||
                       key.startsWith(prefix) || 
                       key.equals(prefix);

Mmmm alleen de eerste regel was goed geweest denk ik

key & prefix zijn beide String

Je kan maar nooit zeker genoeg zijn he! ;-)

[.oisyn]

Als ie die 2e startsWith() nou gewoon als eerste had gedaan dan had het nog net zo snel geperformed ook

[ Voor 7% gewijzigd door .oisyn op 14-02-2009 00:31 ]

[Zoijar]

Woy schreef op vrijdag 13 februari 2009 @ 14:56:
De C# compiler maakt er de volgende IL van

"een". volgens mij is het in C# net zo goed ongedefinieerd, maar ik kan me vergissen.

[.oisyn]

Nee dat was een fout in de MSDN .
Mijn lokale versie die bij VC 2008 komt zegt idd:

When two operators with the same precedence are present in an expression, they are evaluated based on associativity. Left-associative operators are evaluated in order from left to right. For example, x * y / z is evaluated as (x * y) / z. Right-associative operators are evaluated in order from right to left. The assignment operators and the tertiary operator (?: ) are right-associative. All other binary operators are left-associative. However, C# standard does not specify when, in an expression, the "set" portion of an increment instruction is executed. For example, the output of the following example code is 6:

C#:

int num1 = 5;
num1++;
System.Console.WriteLine(num1);

However, the output of the following example code is undefined:

C#:

int num2 = 5;
num2 = num2++;  //not recommended
System.Console.WriteLine(num2);

Echter, in de online versie van die pagina staat dat niet, en in de change history onderaan die pagina staat:

Removed erroneous statement about undefined output.

Aangezien de = operator rechts-associatief is, wordt num++ éérst geevalueerd.

[ Voor 3% gewijzigd door .oisyn op 14-02-2009 03:29 ]

[Zoijar]

ah ok, dat wist ik niet.

Dan staat er idd dit:

C#:

int postfixplusplus(ref int x) {
   int tmp = x;
   x = x + 1;
   return tmp;
}
num2 = postfixplusplus(ref num2);

[Saven]

Hier ook een uur mee zitten kloten:

PHP:

$file = 'forum_view.tpl';

///////////////////////////
$file = 'index.php' //voor error debugging

include($file);

niet echt precies mijn code, maar het geeft een voorbeeld als ik de hele code zou posten zou je een lang script krijgen. ben ik echt uren mee bezig geweest

[Verwijderd]

Ik vind C++ een hele mooie, logische, en krachtige taal. Het is prettig om te weten dat een 'char' gewoon een byte in je geheugen is, waarvan je het adres kan opvragen. Geen abstracties en beperkingen die het veiliger moeten maken zoals bij Java en C#. Maar die syntax...

C++:

int main()
{
    int a = 23;
    int *b = &a;
    int &c = *b;
    
    c = 47 & *b;
    c = a * *b - c;
    
    return a;
}

Dit heb ik uiteraard expres zo geschreven. Je ziet hier de '*' en de '&' beide op 3 verschillende manieren gebruikt worden. De '*' als pointer declaratie, dereferencing operator, en vermenigvuldigingsoperator. De '&' als address-of operator, reference declaratie, en bitwise AND operator. Geen wonder dat C++ nogal verwarrend is voor beginners.

Ik stel voor om een mini-uitbreiding te maken, die voor deze 6 verschillende taken 6 verschillende tekens gebruikt. Volgens mij hebben we nog '@', '#', '$', '%' over.

[ Voor 4% gewijzigd door Verwijderd op 22-02-2009 05:46 ]

[g4wx3]

ken c niet maar zou het niet dat..:
% = modulus volgens mij
# = is commentaar
$ zou je nog eventueel kunnen gebruiken, maar @ zou ik niet gebruiken in programmeertalen (intuïtie)

[dcm360]

@ wordt in (enkele?) programmeertalen gebruikt om af te dwingen dat er geen foutmeldingen gegeven worden

[ Voor 5% gewijzigd door dcm360 op 22-02-2009 10:08 ]

[H!GHGuY]

Woy schreef op woensdag 11 februari 2009 @ 09:14:
Het was inderdaar niet al te serieus bedoeld ( vandaar de ), maar in de code waarin ik nu bezig ben staan toch wel zulke dingen.

C:

// Wait while SPI transfer is in progress
while (!(*SPI_STATUS & 0x00000001)) ;

Inderdaad niet met geneste if's want dat is nogal zinloos als je niet iets anders doet tussen de if/else

Dit komt me bekend voor. Toevallig geen code van Texas Instruments binnen een MV Kernel?

Voorbeeldjes van hun code:

C:

// SPI_controller_driver.c
static struct XXX_spi_config_t spi_config; // niet geinitialiseerd!

static int XXX_spi_setup_transfer(struct spi_device* spi, ...)
{
   ...
   spi->controller_data = NULL;
   spi->controller_data = &spi_config;
   /* moet zijn:
    * if (spi->controller_data == NULL)
    *     spi->controller_data = &spi_config
    */
   ...
}

// some_spi_eeprom_driver.c
static int spi_generic_config(XXX_spi_config_t* spi_cfg)
{
  // volledige initialisatie van spi_cfg
}

static int __devinit eeprom_probe(struct spi_device* spi)
{
  ...
  // controller data van 1 bepaalde controller wijzigen binnen een device 
  // driver en het dan nog _generic_ durven noemen!
  spi_generic_config(spi->controller_data);
  ...
}

Dit gebeurde in de code flow:
- de default config struct was niet geinitialiseerd en de controller data stond op NULL
- in de XXX_spi_setup_transfer werd vervolgens de default toegewezen.
- deze default werd dan ingevuld in de EEPROM driver.

Alles werkt! Tot je een ander SPI device gebruikt natuurlijk!

Het staat dan bovendien nog eens vol met

C:

while (XXX_spi_base->SPI_BUF & SPI_SPIBUF_RXEMPTY_MASK) ;

Waar je te tegenaan loopt als je bepaalde settings niet juist instelt. Mooie trial and error dus als je je eigen SPI device wilt gaan gebruiken

Verbaast het je als dan doorheen hun code volgend statement staat:

C:

MODULE_AUTHOR("Texas Instruments India");

[ Voor 59% gewijzigd door H!GHGuY op 22-02-2009 11:06 ]

[Janoz]

Verwijderd schreef op zondag 22 februari 2009 @ 05:45:
Ik vind C++ een hele mooie, logische, en krachtige taal. Het is prettig om te weten dat een 'char' gewoon een byte in je geheugen is, waarvan je het adres kan opvragen. Geen abstracties en beperkingen die het veiliger moeten maken zoals bij Java en C#.

Het is niet (alleen) om het veiliger te maken, maar vooral om het überhaupt werkend te maken voor applicaties die een andere dan de engelse taal gebruiken. Voor als je perse met bytes wilt werken kun je (in java) het type 'byte' gebruiken.

[Soultaker]

Dat is dus weer geen byte, maar een 8-bits integer.

(Toegegeven, architecturen met bytes van meer dan 8 bits zijn behoorlijk zeldzaam tegenwoordig.)

[Robtimus]

g4wx3 schreef op zondag 22 februari 2009 @ 10:03:
$ zou je nog eventueel kunnen gebruiken, maar @ zou ik niet gebruiken in programmeertalen (intuïtie)

$ kan gebruikt worden in namen van variabelen en functies.

! is not en ^ (pointer declaratie + dereferencing in Delphi) is xor, dus @ zou de enige optie zijn eigenlijk.

[.oisyn]

g4wx3 schreef op zondag 22 februari 2009 @ 10:03:
# = is commentaar

Niet in C of C++, maar # is wel een preprocessor symbol.

dcm360 schreef op zondag 22 februari 2009 @ 10:08:
@ wordt in (enkele?) programmeertalen gebruikt om af te dwingen dat er geen foutmeldingen gegeven worden

Alleen in PHP vziw, dus lekker boeiend . Het gaat hier om C en C++.

IceManX schreef op zondag 22 februari 2009 @ 14:36:
[...]

$ kan gebruikt worden in namen van variabelen en functies.

Niet in C of C++.

Overigens gaat DOT's verhaal ook op voor % en ^ in C++/CLI.

[ Voor 31% gewijzigd door .oisyn op 22-02-2009 16:45 ]

[Verwijderd]

Soultaker schreef op zondag 22 februari 2009 @ 13:31:
Dat is dus weer geen byte, maar een 8-bits integer.

(Toegegeven, architecturen met bytes van meer dan 8 bits zijn behoorlijk zeldzaam tegenwoordig.)

Is een byte (by eight) niet per definitie 8 bits?

[HawVer]

.oisyn schreef op zondag 22 februari 2009 @ 16:43:
[...]
Alleen in PHP vziw, dus lekker boeiend . Het gaat hier om C en C++.

En in C#

C#:

string test = @"ejkjke\eee\ed";

[Verwijderd]

Dit is geen afdwingen van foutmeldingen voor zover ik weet, maar voorkomt escape sequences

HawVer schreef op zondag 22 februari 2009 @ 17:06:
[...]

En in C#

C#:

string test = @"ejkjke\eee\ed";

[Sebazzz]

Verwijderd schreef op zondag 22 februari 2009 @ 17:20:
Dit is geen afdwingen van foutmeldingen voor zover ik weet, maar voorkomt escape sequences

[...]

Klopt. Niks 'nasty' aan.

[curry684]

Verwijderd schreef op zondag 22 februari 2009 @ 16:48:
[...]

Is een byte (by eight) niet per definitie 8 bits?

Helaas:

quote: http://en.wikipedia.org/wiki/Byte#History

The term "byte" comes from "bite," as in the smallest amount of data a computer could "bite" at once.

En een byte kan 2..* bits bevatten afhankelijk van architectuur en/of OS van een systeem. Dat het sinds zeg een jaar of 1970 op 99.99999999% van de computers 8 bits is - tja

[Verwijderd]

Aangezien de = operator rechts-associatief is, wordt num++ éérst geevalueerd.

Dit heeft toch niets te maken maken met de associatieviteit van de = operator? Het gaat er hier om dat de de postfix ++ operator een hoger precedence heeft dan de assignment operator. De 'precedence' bepaalt welke operator een operand 'wint':

C#:

num2 = (num2++);  // als ++ operator hoger precedence heeft
(num2 = num2)++;  // als assignment operator hogere precedence heeft

Aangezien de assignment operator de laagst mogelijke precedence heeft geldt dus de eerste situatie: eerst wordt (num2++) geevalueerd. Maar aangezien de postfix operator inhoudt dat de waarde eerst wordt gebruikt en dan pas wordt verhoogd, zou je verwachten dat er dit gebeurt:

C#:

num2 = num2;
num2++;

[.oisyn]

Verwijderd schreef op zondag 22 februari 2009 @ 18:54:
[...]


Dit heeft toch niets te maken maken met de associatieviteit van de = operator?

Op zich niet, ware het niet dat C# definieert dat de order of evaluation gelijk is aan de associativiteit van de operator

Het gaat er hier om dat de de postfix ++ operator een hoger precedence heeft dan de assignment operator. De 'precedence' bepaalt welke operator een operand 'wint'

Wat nog niet wil zeggen wanneer de side-effects van de postfix increment daadwerkelijk worden afgerond. C++ kent dezelfe associativiteit en precedence, maar toch is de order of evaluation niet gedefinieerd waardoor een expressie als n = n++ resulteert in undefined behaviour. Omdat het niet duidelijk is wanneer de nieuwe waarde van n na ophoging daadwerkelijk wordt weggeschreven - dat kan zowel voor als na de assignment. Bij C# is het altijd ervoor.

Als de postfix increment een lagere precedence zou hebben dan de assignment dan is die ambiguiteit er niet eens meer (moet de assignment operator wel resulteren in een l-value anders kan het al niet eens)

[Robtimus]

.oisyn schreef op zondag 22 februari 2009 @ 16:43:
[...]

Niet in C of C++.

Wel in mijn MinGW GCC installatie. Ik had het al getest, anders had ik het nooit met zoveel zekerheid durven zeggen.

[.oisyn]

Dat maakt het nog geen standaard C of C++ .

[Sebazzz]

Je zou bijna zo slecht programmeren omdat het tot geweldige discussies kan leiden

Welke zou jij doen? (pseudocode)

C#:

abstract class A {
    string _x;
    
    public string X {
        get {
            return _x;
        } set {
            _x = value;
        }
    }
    
    // nog veel meer properties
    
    public abstract string[] Methode(int getal);
}

// implementatie
class B : A {
    public B() {
        _x = "test";
    }
    
    public string[] Methode( int getal ) {
        // code
    }
}

C#:

interface A {
    public string GetX();
    public string SetX(string x);
    
    public string[] Methode( int getal );
}

// impl
class B : A {
    string _x;
    
    public string GetX() {
        return _x;
    }
        
    public string SetX(string x) {
        return _x = x;
    }
    
    public string[] Methode( int getal ) {
        // code
    }
}

In deze context:

C#:

A aah = null;
if (radio_B.Checked) {
    aah = new B();
} else if (radio_C.Checked) {
    aah = new C();
} //etc

aah.Property = x;
aah.Andere_prop = y;
if (aah.KanIets) {
    aah.DoeIets();
} else {
    aah.DoeNiets();
}
int ander_getal = aah.DoeNogWat(getalletje);

[ Voor 88% gewijzigd door Sebazzz op 22-02-2009 21:04 ]

[Jaap-Jan]

curry684 schreef op zondag 22 februari 2009 @ 18:33:
[...]

Helaas:
(...)

Niet voor niets heet een halve byte ook een nibble.

Verwijderd schreef op zondag 22 februari 2009 @ 05:45:
Ik vind C++ een hele mooie, logische, en krachtige taal. Het is prettig om te weten dat een 'char' gewoon een byte in je geheugen is, waarvan je het adres kan opvragen. Geen abstracties en beperkingen die het veiliger moeten maken zoals bij Java en C#. Maar die syntax...

C++:

int main()
{
    int a = 23;
    int *b = &a;
    int &c = *b;
    
    c = 47 & *b;
    c = a * *b - c;
    
    return a;
}

Ik stel voor om een mini-uitbreiding te maken, die voor deze 6 verschillende taken 6 verschillende tekens gebruikt. Volgens mij hebben we nog '@', '#', '$', '%' over.

@ als dereference operator.

' of ` kan als address-of operator.

Even denken wat voor teken voor een reference. # kan niet, zoals .oisyn al opmerkte. Je ontkomt eigenlijk niet aan het dubbel definieren van operators, want voor de rest zijn alle 'speciale' basis ASCII- tekens wel in gebruik in C en C++.

$ om een pointervariabele te maken.

* en & houden gewoon hun 'normale' definitie van vermenigvuldigen en bitwise-AND.

Ik had zelf om die reden zoveel moeite met het begrijpen van pointers en references in C en/of C++. Ik had eerst niet door dat die & en * dubbel gebruikt voor voor definitie en address-of en deference operator.

[ Voor 93% gewijzigd door Jaap-Jan op 22-02-2009 21:45 ]

[TvdW]

Ik vond deze ook wel erg leuk :

(17:54:45) JaNuZ -:

code:

<?
$msg = strtolower($_GET['msg']);
if($msg == 'Start'){
echo "$msg";
}
?>

(17:54:48) JaNuZ -: dat werkt niet eens

(MSN gesprek)

[Sh4wn]

TvdW schreef op dinsdag 03 maart 2009 @ 17:58:
Ik vond deze ook wel erg leuk :

[...]

(MSN gesprek)

Om van te huilen

[ Voor 78% gewijzigd door Sh4wn op 03-03-2009 18:00 ]

[link0007]

- geen indenting
- de variabele tussen double quotes zetten als je enkel de variabele print

oh, en de mierenneukerparser (error level USER_SPILLEDMILK):
- gebruik van short tags (<? ?>)


En ja, dat hij een hoofdletter in z'n if-je heeft staan zie ik wel, maar dat is moeilijk een slecht programmeervoorbeeld te noemen. Zo'n dingen gebeuren nu eenmaal.

[ Voor 30% gewijzigd door link0007 op 03-03-2009 18:32 ]

[.oisyn]

Het komt van MSN, waarschijnlijk is de indenting gewoon verloren gegaan

[Verwijderd]

TvdW schreef op dinsdag 03 maart 2009 @ 17:58:
Ik vond deze ook wel erg leuk :

[...]

(MSN gesprek)

Ah, dan lig je toch ff plat van het lachen

[Sebazzz]

Niet eens een slecht programmeervoorbeeld maar eerder een slecht user interface design.

Bij onze supermarkt gebruiken we een toepassingen programma dat direct op de database zit. Daarin worden verschillende applicaties aangeboden, onder andere het DASA (Decentraal Assortiments Systeem AH). Hierin staan alle producten van de supermarkt.

Het leuke van dit systeempje is dat je in het programma alleen functietoetsen kan gebruiken die gedefineerd zijn (logisch) maar de functietoetsen die niet gedefineerd zijn, geeft hij een grote error op. Daarnaast staan veel velden die wél readonly moeten zijn maar niet zo gemarkeerd zijn (dus gewoon een normaal tekstveld zijn). Als je erin typt krijg je errors. Om er wat in te typen moet je F7 drukken.

Daarnaast staan er geen sneltoetsen in de menu's vermeld terwijl die er wél zijn. En bij een vraag messagebox krijg je een warning icoontje, en bij een informatie messagebox een stop icoontje.

Daarnaast is het denk ik ook niet beveiligd. Als je alles van chocomel wilt weten typ je '%chocomel%' (note de '%' ofwel een interne LIKE). Maar met ' OR '1'='1 krijg je alles! Gelukkig hebben ze een hele mooie optie hiervoor, namelijk aparte accounts voor de database. En deze dan geen DELETE rechten geven om het probleem op te lossen.

Het uren programma zit ook goed in elkaar. Deze pakt alleen hele kwartieren (vermoedelijk wordt het dus intern naar decimalen omgerekent) en 10:48 past er dus niet in.

[chime]

Sebazzz schreef op dinsdag 03 maart 2009 @ 21:53:

Daarnaast is het denk ik ook niet beveiligd. Als je alles van chocomel wilt weten typ je '%chocomel%' (note de '%' ofwel een interne LIKE). Maar met ' OR '1'='1 krijg je alles! Gelukkig hebben ze een hele mooie optie hiervoor, namelijk aparte accounts voor de database. En deze dan geen DELETE rechten geven om het probleem op te lossen.

De applicatie is dus niet beveiligd tegen sql injection.

Het is dan te hopen dat die accounts dus ook geen drop / truncate rechten hebben ;-)
Maar zelfs met update statements kan je het systeem overhoop halen.

Als die applicatie dus ook bepaald welke prijzen aangerekend worden, is dit eigenlijk wel een vrij groot risico ...

[Snake]

Sebazzz schreef op dinsdag 03 maart 2009 @ 21:53:
Niet eens een slecht programmeervoorbeeld maar eerder een slecht user interface design.

Bij onze supermarkt gebruiken we een toepassingen programma dat direct op de database zit. Daarin worden verschillende applicaties aangeboden, onder andere het DASA (Decentraal Assortiments Systeem AH). Hierin staan alle producten van de supermarkt.

Het leuke van dit systeempje is dat je in het programma alleen functietoetsen kan gebruiken die gedefineerd zijn (logisch) maar de functietoetsen die niet gedefineerd zijn, geeft hij een grote error op. Daarnaast staan veel velden die wél readonly moeten zijn maar niet zo gemarkeerd zijn (dus gewoon een normaal tekstveld zijn). Als je erin typt krijg je errors. Om er wat in te typen moet je F7 drukken.

Daarnaast staan er geen sneltoetsen in de menu's vermeld terwijl die er wél zijn. En bij een vraag messagebox krijg je een warning icoontje, en bij een informatie messagebox een stop icoontje.

Daarnaast is het denk ik ook niet beveiligd. Als je alles van chocomel wilt weten typ je '%chocomel%' (note de '%' ofwel een interne LIKE). Maar met ' OR '1'='1 krijg je alles! Gelukkig hebben ze een hele mooie optie hiervoor, namelijk aparte accounts voor de database. En deze dan geen DELETE rechten geven om het probleem op te lossen.

Het uren programma zit ook goed in elkaar. Deze pakt alleen hele kwartieren (vermoedelijk wordt het dus intern naar decimalen omgerekent) en 10:48 past er dus niet in.

What about UPDATE? En DROP?

[Haan]

Sebazzz schreef op dinsdag 03 maart 2009 @ 21:53:
Het uren programma zit ook goed in elkaar. Deze pakt alleen hele kwartieren (vermoedelijk wordt het dus intern naar decimalen omgerekent) en 10:48 past er dus niet in.

Wie gaat er dan ook op de minuut nauwkeurig uren bijhouden? Hele kwartieren vind ik al redelijk nauwkeurig. Maar het zou idd mooier zijn geweest als dat automatisch werd afgerond naar het dichtsbijzijnde kwartier ofzo.

[bat266]

Is dat nu slecht voorbeeld bij de AH werktijden? Ik vind van niet het had natuurlijk netter gekund idd door zelf af te ronden. Maar als er zelf wordt afgerond door het systeem en dat wordt niet gecommuniceerd (tenminste niet goed) dan heb je denk ik een groter probleem dan dat er vanzelf duidelijk wordt dat die afronding noodzakelijk is. Verder zou ik voor een minuten systeem gaan, maar dat is een keuze.

[Voutloos]

Sebazzz schreef op dinsdag 03 maart 2009 @ 21:53:
Niet eens een slecht programmeervoorbeeld maar eerder een slecht user interface design.
...
Daarnaast is het denk ik ook niet beveiligd. Als je alles van chocomel wilt weten typ je '%chocomel%' (note de '%' ofwel een interne LIKE). Maar met ' OR '1'='1 krijg je alles! Gelukkig hebben ze een hele mooie optie hiervoor, namelijk aparte accounts voor de database. En deze dan geen DELETE rechten geven om het probleem op te lossen.

Enorme WTF. Elke persoon die zegt dat het met het beperken van DELETE rechten opgelost is moet ter plekke ontslagen worden en mag voor de rest van zijn leven tomaten plukken.

[TaraWij]

Verwijderd schreef op zondag 22 februari 2009 @ 05:45:

C++:

int main()
{
    int a = 23;
    int *b = &a;
    int &c = *b;
    
    c = 47 & *b;
    c = a * *b - c;
    
    return a;
}

Ik stel voor om een mini-uitbreiding te maken, die voor deze 6 verschillende taken 6 verschillende tekens gebruikt. Volgens mij hebben we nog '@', '#', '$', '%' over.

Dat lijkt me vrij overbodig, bekijk de code als volgt:

C++:

int main()
{
    // a is een integer.
    int a = 23;

    // b is een POINTER naar een integer, geïnitialiseerd met het ADRES van a.
    int * b = &a;

    // c is een REFERENCE naar een integer, geïnitialiseerd met de WAARDE van de pointer naar b.
    int & c = *b;
    
    c = 47 & (*b);
    c = a * (*b) - c;
    
    return a;
}

Bij de declaratie van de variabele gaat het steeds om een pointer of reference, bij het initialiseren of toewijzen gaat het steeds om het adres of waarde. Verder plaats ik bij de declaratie de * of & apart omdat het een woord op zich is en niet lijkt op een adres of waarde, die tegen het type laten plakken vind ik ook niet netjes.

Het toevoegen van extra symbolen voor deze operaties maakt het meer verwarrend of drukker, je gaat namelijk nog meer te begrijpen symbolen voorzien voor zaken die slechts te maken hebben met twee dingen: Refereren en de-refereren.

(Verwarring met de vermenigvuldiging-operator heb ik nog niet weten voorkomen)

[MBV]

tegen het type plakken is ook onjuist, kijk maar:

C:

int* b, c;
c = 5;
b = &c;

c is een int, b is een pointer. Daar heb ik ooit heel lang naar gezocht...

[.oisyn]

C++ is daar sowieso een beetje "krom" in

C++:

int const a, b;             // b: const int
int const * a, b;           // b: const int
int * const a, b;           // b: int
int const * const a, b;     // b: const int

Wmb had een definitie gewoon bestaan uit een type gevolgd door een of meer variabel-namen. Ook voor pointers naar functies e.d.

C++:

// dus niet
int(*bar)[3];
void (*foo)();

// maar
int[3]* bar;
void () * foo;

// en dus ook niet
int (*foo(float(*(*bar)(int))[5])[3] { }

// maar
int[3]* (float[5]* (int) * bar) foo { }
// oftewel, een functie 'foo' met 1 parameter 'bar' (wat een pointer is naar een functie
// die een int accepteert en een pointer naar float[5] returnt) en als returntype een pointer
// naar int[3]

Het slaat natuurlijk nergens op dat het hoofd-type van de declaratie toevallig als return-waarde wordt genomen. Ik bedoel:

C++:

int a, (*b)(), c;

Wat heeft int überhaupt nog met b te maken, behalve dat het toevallig de returntype is van die functiepointer?

[ Voor 25% gewijzigd door .oisyn op 04-03-2009 12:09 ]

[Verwijderd]

Voutloos schreef op woensdag 04 maart 2009 @ 09:10:
[...]
Enorme WTF. Elke persoon die zegt dat het met het beperken van DELETE rechten opgelost is moet ter plekke ontslagen worden en mag voor de rest van zijn leven tomaten plukken.

DASA wordt bij een heule boel Albert Heijns gebruikt, zo zijn er nog wel tig voorbeelden te noemen van enorme pakketten waar enorme stupiditeiten in zitten. De gewoonste zaak van de wereld hoor.

[Woy]

Verwijderd schreef op woensdag 04 maart 2009 @ 12:29:
[...]

DASA wordt bij een heule boel Albert Heijns gebruikt, zo zijn er nog wel tig voorbeelden te noemen van enorme pakketten waar enorme stupiditeiten in zitten. De gewoonste zaak van de wereld hoor.

Maar daarom geen minder grote WTF!

[Sebazzz]

Het programma is ook erg inconsistent met zijn meldingen. Als iets niet gevonden kan worden dan wordt dit in de statusbalk weergegeven en het veld waar je in bezig was wordt unfocused. Maar als je een prijswijziging opslaan krijg je een foutmelding dat de prijswijzigingen succesvol zijn opgeslagen (messagebox in plaats van statusbalk).

Ik vermoed overigens dat het niet kunnen gebruiken van Ctrl+A (Alles selecten) in een veld (en meer standaard functietoetsen danwel niet gedefineerde functie) een voorbeeld van goed bedoelde gebruiksvriendelijkheid zijn want je krijgt de melding om dan voor hulp op Ctrl+F1 te drukken.

Wat ook heel vervelend is dat normaal tabben door een formulier niet mogelijk is terwijl het allemaal standaard WinForms zijn. De tab toets wordt bij bepaalde velden gewoon geblokkeerd.

[ Voor 21% gewijzigd door Sebazzz op 04-03-2009 14:50 ]

[Verwijderd]

Enkele stukjes code uit een site die ik op mijn stageplaats moet aanpassen:

PHP:

addslashes(htmlentities(md5($_REQUEST["txtWacht"])))

PHP:

if (isset($_GET['t'])) {
  //doe iets
} else if (isset($_GET['i'])) {
  if (isset($_GET['t'])) {
    // doe iets
  }
}

En zo staan er nog wel een hoop tussen...

[Sebazzz]

Dat krijg je als je gewoon het essentiële inzicht mist dat je voor programmeren nodig hebt. Je kan het of je kan het niet. Je kan het dan wel vaak beter, maar je moet als je code leest de complete mogelijke flow van de code in één klap kunnen doorzien want anders zal je dit soort fouten maken en imho nooit goed programmeren. Programmeren is gewoon een talent. Je kan piano spelen leren ja, maar je zal nooit zo goed worden als Wibi. Dit klinkt wat hard, maar het is mijn mening

[ Voor 22% gewijzigd door Sebazzz op 04-03-2009 15:47 ]

[YopY]

Sebazzz schreef op woensdag 04 maart 2009 @ 15:21:
Dat krijg je als je gewoon het essentiële inzicht mist dat je voor programmeren nodig hebt. Je kan het of je kan het niet. Je kan het dan wel vaak beter, maar je moet als je code leest de complete mogelijke flow van de code in één klap kunnen doorzien want anders zal je dit soort fouten maken en imho nooit goed programmeren. Programmeren is gewoon een talent. Je kan piano spelen leren ja, maar je zal nooit zo goed worden als Wibi. Dit klinkt wat hard, maar het is mijn mening

^dit. Hetzelfde geldt voor OOP, dat moet je gewoon 'zien', doorhebben, snappen, etc. Dat, en toepassen wat slimme mensen zeggen, .

[MBV]

Sebazzz schreef op woensdag 04 maart 2009 @ 15:21:
Programmeren is gewoon een talent. Je kan piano spelen leren ja, maar je zal nooit zo goed worden als Wibi. Dit klinkt wat hard, maar het is mijn mening

Talent is voor 3/4 gewoon hard oefenen. Mensen die heel goed piano kunnen spelen, hebben dat op jonge leeftijd al zoveel gedaan, dat haal je als volwassene bijna niet meer in.

[kenneth]

Uh, nee.

Talent is talent.

Er zijn kinderen zijn die op extreem jonge leeftijd al heel vaardig zijn in bijv. piano spelen, terwijl ze nog niet de tijd gehad hebben om veel te kunnen oefenen.

Wat betreft oefenen heb je natuurlijk wel een punt: Oefenen icm talent zorgt voor vaardigheid. Hoe minder talent, hoe harder je moet oefenen om een bepaald niveau te halen. Hoe meer talent, hoe minder je hoeft te oefenen om hetzelfde niveau te halen.

[.oisyn]

@MBV: Dat is dus geen talent. Talent is per definitie iets wat aangeboren is en wat dus niet te oefenen is. Sommige mensen hebben geen gevoel voor maat of toonhoogten. Die kunnen hooguit stukjes goed uit hun hoofd leren, ze zullen echter nooit goed piano kunnen spelen. Dit geldt ook voor programmeren.

Neemt niet weg dat talent beter tot z'n recht komt bij goed oefenen, en dat het dus niet wil zeggen dat iemand die meer getalenteerd is ook per definitie beter is. Maar hij zou wel beter kunnen zijn.

Interessant leesvoer over talent bij programmeren

.edit: @kenneth: ja dat zeg ik toch

[ Voor 3% gewijzigd door .oisyn op 04-03-2009 17:09 ]

[MBV]

offtopic:
Ik heb gelezen (krant, waarschijnlijk NRC next) dat kinderen die talent hebben voor pianospelen de mogelijkheid hebben om goed piano te kunnen spelen. Geef ze een stel ouders dat veel klassieke muziek luistert, vaak zelf piano speelt, en de mogelijkheid om achter die piano te kruipen, dan zullen ze op den duur goed kunnen spelen. Geef ze die kans niet, en ze zullen het, ook op latere leeftijd, slecht kunnen leren.

Maar dat talent is alleen 1/4 ofzo. Iemand met veel talent pikt het eerste stuk veel sneller op, en zal dus meer gemotiveerd zijn om verder te oefenen. Als zo iemand daardoor 5 uur per dag gaat oefenen, dan krijg je een Wibi de 2e. Had je mij (beetje talent) kunnen motiveren om 6 uur te oefenen, dan had ik misschien net zo goed gespeeld.

[P-Storm]

Als iemand hier de Zeef van Eratosthenes kent, dan snap je misschien waarom de eerste Zeef niet goed is. Zelf heb ik snel de onderstaande zeef gemaakt. Kwam deze code (in de vorm van visual basic) tegen op Wikipedia (zie bovenstaande link)

Visual Basic .NET:

  Private Function zeef(ByVal ZoekenTotGetal As Integer) As List(Of Integer)
    Dim priem As New List(Of Integer) 'lijst met priem getallen
    Dim Prime(ZoekenTotGetal) As Boolean        '** Effe Dimme **

    For I As Integer = 2 To ZoekenTotGetal
      Prime(I) = 1                                    '** Alles naar 1 **
      For J As Integer = 2 To ZoekenTotGetal
        If I Mod J = 0 And I <> J Then
          Prime(I) = 0                            '** Geen Priem dan 0
        End If
      Next J
      If Prime(I) Then priem.Add(I) '** Zet op je form wat 1 is **
    Next I
    Return priem
  End Function

Visual Basic .NET:

  Private Function zeef(ByVal ZoekenTotGetal As Integer) As List(Of Integer)
    Dim filter(ZoekenTotGetal) As Boolean 'alle getalleen tot ZoekenTotGetal
    Dim priem As New List(Of Integer) 'lijst met priem getallen

    For I As Integer = 2 To ZoekenTotGetal
      If filter(I) = False Then 'als getal niet uitgefilterd is
        priem.Add(I) 'dan is het priem
        For J As Integer = I To ZoekenTotGetal Step I 'en filter je alle getallen met priemfactor eruit
          filter(J) = True
        Next
      End If
    Next
    Return priem
  End Function

[.oisyn]

MBV schreef op woensdag 04 maart 2009 @ 17:40:
Maar dat talent is alleen 1/4 ofzo.

Dat zei je niet. En wij ontkennen niet dat veel oefenen belangrijk(er) is voor de ontwikkeling. Maar je zei dat 3/4e van het talent gewoon oefenen is. Waarschijnlijk bedoel je dus 3/4e van de vaardigheid is oefenen, en 1/4e is talent.

Daarnaast stel ik: mensen met 0 talent kunnen oefenen wat ze willen, ze zullen nooit goed worden.

[Sebazzz]

.oisyn schreef op woensdag 04 maart 2009 @ 18:06:
[...]

Daarnaast stel ik: mensen met 0 talent kunnen oefenen wat ze willen, ze zullen nooit goed worden.

Ik durf wel te zeggen dat de meeste rare constructies komen van mensen die een essentieel stukje talent of inzicht (natuurlijk is inzicht hebben ook een talent hoewel je het wel kan kweken) missen.

Iets anders: Wat iedereen bij programmeren wel eens kan doen is stukken code overnieuw schrijven. Je implementeert een idee of een algoritme of wat dan ook. Je laat het voor wat het is, en een week of wat later schrijf je dat stuk code opnieuw. Gegarandeerd dat je er geen spijt van krijgt Laatst stond op Coding Horror hier ook een stuk over. Ik doe het, en het bevalt.

[MBV]

.oisyn schreef op woensdag 04 maart 2009 @ 18:06:
[...]

Dat zei je niet. En wij ontkennen niet dat veel oefenen belangrijk(er) is voor de ontwikkeling. Maar je zei dat 3/4e van het talent gewoon oefenen is. Waarschijnlijk bedoel je dus 3/4e van de vaardigheid is oefenen, en 1/4e is talent.

Daarnaast stel ik: mensen met 0 talent kunnen oefenen wat ze willen, ze zullen nooit goed worden.

Mijn excuses voor de bewoording, maar dat was wel precies wat ik bedoelde. Dat wat mensen als talent zien (MBV kan heel goed piano spelen, echt een talent) is maar voor een klein deel erfelijk, en voor een heel groot deel oefening.

En ook mensen die niet getalenteerd zijn in een gebied kan je dingen leren, mits ze graag willen (erg moeilijk om door het eerste stuk te gaan zonder talent) en intelligent genoeg zijn. Dan kan je intelligentie ook als talent zien, maar ik dacht niet dat we het daar over hadden.

Maar goed, ik ben geen deskundoloog op dat vlak, dus dikke kans dat ik er volledig naast zit. Ik hoop het niet, er zijn nog wat dingen die ik wil leren waar ik geen talent voor heb

[ Voor 3% gewijzigd door MBV op 14-03-2009 00:01 ]