[alg] Slechtste programmeervoorbeelden deel 4

[sopsop]

Laatst zag ik hier op mijn werk een tabel in SQL Server gedefinieerd als:

SQL:

CREATE TABLE [dbo].[Table_1](
    [PrimaryKey] [int] IDENTITY(1,1) NOT NULL,
    [Veld1] [varchar](50) NULL,
    [Veld2] [varchar](50) NULL
) ON [PRIMARY]

Spot the problem... Er zaten 1,5 miljoen records in deze tabel en men had wat klachten over de performance.

_{PrimaryKey was de echte kolomnaam, Veld1 en Veld2 representeren een kolom of 20}

[ Voor 24% gewijzigd door sopsop op 23-03-2010 14:51 ]

[Tanuki]

Nog een hele leuke: DHL For You Gratis pakketten versturen

[dev10]

l0c4lh0st schreef op dinsdag 23 maart 2010 @ 19:02:
Nog een hele leuke: DHL For You Gratis pakketten versturen

Dat ga je niet menen. Ik heb op de afdeling stage gelopen die die website moest onderhouden. Iemand heeft besloten dat er met SharePoint gewerkt moest worden daarvoor, en degenen die het moesten onderhouden hadden geen kaas gegeten van SharePoint en zaten altijd te schelden als er iets aangepast moest worden.

[mindcrash]

dev10 schreef op dinsdag 23 maart 2010 @ 20:19:
Iemand heeft besloten dat er met SharePoint gewerkt moest worden daarvoor, en degenen die het moesten onderhouden hadden geen kaas gegeten van SharePoint en zaten altijd te schelden als er iets aangepast moest worden.

Was er geen budget voor een fatsoenlijke training dan? First time SharePoint users hebben (ook voor WCM) minstens een workshop van zo'n 2 dagen nodig om aan het pakket te "wennen".

Overigens best een interessante architectuurkeuze: ASP.NET plus SharePoint plus PHP op dezelfde server (schijnbaar)

[ Voor 18% gewijzigd door mindcrash op 23-03-2010 21:07 ]

[dev10]

mindcrash schreef op dinsdag 23 maart 2010 @ 21:06:
[...]


Was er geen budget voor een fatsoenlijke training dan? First time SharePoint users hebben (ook voor WCM) minstens een workshop van zo'n 2 dagen nodig om aan het pakket te "wennen".

Overigens best een interessante architectuurkeuze: ASP.NET plus SharePoint plus PHP op dezelfde server (schijnbaar)

Tja, geen idee. Toen ik er begon anderhalf jaar geleden, was draaide het net. Ik heb de launch niet meegemaakt.

[Alex)]

mindcrash schreef op dinsdag 23 maart 2010 @ 21:06:
[...]
Overigens best een interessante architectuurkeuze: ASP.NET plus SharePoint plus PHP op dezelfde server (schijnbaar)

Toch niet... de invoerpagina is gehost op een andere server en wordt via een iframe getoond.

[TUX2K]

Kom net wat leuks tegen in de code:

C#:

if (!string.IsNullOrEmpty(Request["id"].Trim()))
   GUID userID = new Guid(Request["id"].Trim());

GetUser( userID.ToString());

Waarna in de functie GetUser het volgende gebeurde:

C#:

public static DataRow GetUser (string userID)
{
  Guid userGuid = new Guid( userID );
}

Was geloof ik nog niet helemaal wakker toen dat gebouwd werd.

[ Voor 0% gewijzigd door TUX2K op 24-03-2010 12:06 . Reden: Typo, Koffie machine is stuk moet het met thee doen ]

[Matis]

TUX2K schreef op woensdag 24 maart 2010 @ 11:54:
Was geloof ik nog niet helemaal waker toe dat gebouwd werd.

Toen je het bericht typte ook niet helemaal geloof ik

[Woy]

Ok ik heb de hele GET/POST/Uitlog discussie afgesplitst naar: Veiligheid GET/POST bij uitlog functie *

[Verwijderd]

Woy schreef op woensdag 24 maart 2010 @ 12:05:
Ok ik heb de hele GET/POST/Uitlog discussie afgesplitst naar: Veiligheid GET/POST bij uitlog functie *

Bijna de hele.. Oh, de link is na 3 pogingen gelukt zie ik?

[Woy]

Verwijderd schreef op woensdag 24 maart 2010 @ 12:06:
[...]

Bijna de hele.. Oh, de link is na 3 pogingen gelukt zie ik?

offtopic:
Ja copy/paste is best lastig als je teveel dingen tegelijk aan het doen bent . En dan gaan er nog vervelend mensen tussendoor posten als je bezig bent ook

[Wallie]

Man man, wat ik hier aantrof...

Visual Basic .NET:

 Try
            Dim dtAdp As SqlClient.SqlDataAdapter
            dtAdp = New SqlClient.SqlDataAdapter(TheQuery, sqlCon)
            dtAdp.SelectCommand.CommandTimeout = 4000

            Dim dsData As DataSet = New DataSet
            dtAdp.Fill(dsData)

            Return dsData

        Catch ex As OleDb.OleDbException

            If ex.ErrorCode = -2147217842 Then

                Try
                    Dim dtAdp As SqlClient.SqlDataAdapter
                    dtAdp = New SqlClient.SqlDataAdapter(TheQuery, sqlCon)
                    dtAdp.SelectCommand.CommandTimeout = 8000

                    Dim dsData As DataSet = New DataSet
                    dtAdp.Fill(dsData)

                    Return dsData
                Catch ex_1 As Exception
                    Return Nothing
                End Try
            Else
                Return Nothing
            End If
End Try

en vederop nog mooier:

Visual Basic .NET:

Try
            Dim cmdReader As New SqlClient.SqlCommand(TheQuery, sqlCon)
            cmdReader.CommandTimeout = 10000

            Return cmdReader.ExecuteReader()

        Catch ex As OleDb.OleDbException
            If ex.ErrorCode = -2147217842 Then

                Try
                    Dim cmdReader_1 As New SqlClient.SqlCommand(TheQuery, sqlCon)
                    cmdReader_1.CommandTimeout = 0

                    Return cmdReader_1.ExecuteReader()
                Catch ex_1 As Exception
                    Return Nothing
                End Try
            Else
                Return Nothing
            End If
        End Try

[ Voor 26% gewijzigd door Wallie op 25-03-2010 14:18 ]

[Haan]

En errorcode -2147217842 is zeker een timeout?

[Haan]

Leuke kolomnaam kom ik tegen in een dataset: Status123, mogelijke waardes 1,2,3

[Verwijderd]

Haan schreef op vrijdag 26 maart 2010 @ 15:56:
Leuke kolomnaam kom ik tegen in een dataset: Status123, mogelijke waardes 1,2,3

Da's best handig! Dan vergeet je nooit welke waardes hij kan hebben... En als er een waarde bij komt hoef je alleen maar een 4 erachter te plakken...

[boe2]

Wallie schreef op donderdag 25 maart 2010 @ 14:17:
Man man, wat ik hier aantrof...

Ach, waarom niet een paar lagen dieper gaan? Timeout van 16000 en 32000 kan er nog wel bij

[Matis]

Boeboe schreef op vrijdag 26 maart 2010 @ 16:37:
Ach, waarom niet een paar lagen dieper gaan? Timeout van 16000 en 32000 kan er nog wel bij

Niet dat het fraai is, maar je zou het toch ook in een loop kunnen doen en de waitTime ophogen tot een bepaald maximum, dan voorkom je van deze ranzige geneste try-catch constructies.

[Sebazzz]

Wallie schreef op donderdag 25 maart 2010 @ 14:17:
Man man, wat ik hier aantrof...

Code: Visual Basic .NET

Ja Visual Basic .NET is een behoorlijk slecht programmeervoorbeeld

[CoolGamer]

Matis schreef op vrijdag 26 maart 2010 @ 23:04:
[...]

Niet dat het fraai is, maar je zou het toch ook in een loop kunnen doen en de waitTime ophogen tot een bepaald maximum, dan voorkom je van deze ranzige geneste try-catch constructies.

Waarom zou niet gelijk de maximale timeout ingeven? Wat schiet je er mee op om het eerst kort te proberen en daarna langer als het mislukt? Dan is gelijk de max testen een stuk handiger.

[Davio]

Wallie schreef op donderdag 25 maart 2010 @ 14:17:
Man man, wat ik hier aantrof...

[..]

en vederop nog mooier:

Visual Basic .NET:

Try
            Dim cmdReader As New SqlClient.SqlCommand(TheQuery, sqlCon)
            cmdReader.CommandTimeout = 10000

            Return cmdReader.ExecuteReader()

        Catch ex As OleDb.OleDbException
            If ex.ErrorCode = -2147217842 Then

                Try
                    Dim cmdReader_1 As New SqlClient.SqlCommand(TheQuery, sqlCon)
                    cmdReader_1.CommandTimeout = 0

                    Return cmdReader_1.ExecuteReader()
                Catch ex_1 As Exception
                    Return Nothing
                End Try
            Else
                Return Nothing
            End If
        End Try

Ja, 't is mooi geneste soep.

Ten eerste moet je try-catches nooit nesten, dat is gewoon vies.
Ten tweede hoef je natuurlijk geen else te gebruiken als je in de if al returns hebt staan.
Ten derde kun je nog een extra nesting voorkomen door de if om te draaien:

Visual Basic .NET:

If ex.ErrorCode != (of is het <> in vb.net?) -2147217842 Then
  Return Nothing
End If
[i]Hier weer verder zonder nesting.[/i]

En ten slotte: Erg mooi om die integer te gebruiken, maar bestaat er geen enum voor de errors zodat je kan zeggen: If ex = Error.Whatever?

PS: Ik vind het altijd vies als in een taal het teken voor assignment hetzelfde is als het teken voor vergelijken, krijg je van die constructies als x = 2 = 3.

[Verwijderd]

Davio schreef op vrijdag 26 maart 2010 @ 23:43:
[...]

Ten tweede hoef je natuurlijk geen else te gebruiken als je in de if al returns hebt staan.

Ehh.. Ik kan wat missen, ik ken die taal totaal niet, maar waarom geen return als je in de if al returns hebt staan? Als hij niet in de if komt, heb je toch niks aan de returns die daar in staan, of mis ik nou iets?

[H004]

Verwijderd schreef op zaterdag 27 maart 2010 @ 00:09:
[...]

Ehh.. Ik kan wat missen, ik ken die taal totaal niet, maar waarom geen return else als je in de if al returns hebt staan? Als hij niet in de if komt, heb je toch niks aan de returns die daar in staan, of mis ik nou iets?

Dat mis je

Davio bedoelt het volgende:

PHP:

if ($a == $b) {
  return true;
}
return false;

// versus

if ($a == $b) {
  return true;
}
else {
  return false;
}

[ZaZ]

H004 schreef op zaterdag 27 maart 2010 @ 01:21:
[...]

Dat mis je

Davio bedoelt het volgende:

PHP:

if ($a == $b) {
  return true;
}
return false;

// versus

if ($a == $b) {
  return true;
}
else {
  return false;
}

Kan je niet net zo goed dit doen in php? Of is het gooit dat loosetyped gebeuren dan weer roet in het eten.

PHP:

return ($a == $b);

[Verwijderd]

H004 schreef op zaterdag 27 maart 2010 @ 01:21:
[...]

Dat mis je

Davio bedoelt het volgende:

PHP:

if ($a == $b) {
  return true;
}
return false;

// versus

if ($a == $b) {
  return true;
}
else {
  return false;
}

Ik miste het idd. 't Was al laat hè.

ZaZ schreef op zaterdag 27 maart 2010 @ 02:25:
[...]

Kan je niet net zo goed dit doen in php? Of is het gooit dat loosetyped gebeuren dan weer roet in het eten.

PHP:

return ($a == $b);

Dat zou inderdaad in PHP kunnen, heeft verder niks met loosetyped te maken, want een vergelijking levert altijd een boolean op, dus die kan je gewoon direct returnen ipv met een if (/ else). Maar het ging in dit geval niet over PHP, maar de code waar ik op gereageerd had, daar was zo'n verkorte versie dan weer niet mogelijk (of misschien ook wel, aangezien we in dít topic zitten..).

[ Voor 48% gewijzigd door Verwijderd op 27-03-2010 03:25 ]

[Davio]

Die return was in het oorspronkelijke bericht niet mogelijk, omdat daar een object gereturnd wordt ipv een boolean.

[Sc0tTy]

mjah daar kan ik echt niet tegen, een functie waar veel geneste if/elses instaan
gewoon op 1 tabhoogte telkens de checks doen

[Erkens]

Sc0tTy schreef op woensdag 31 maart 2010 @ 10:12:
mjah daar kan ik echt niet tegen, een functie waar veel geneste if/elses instaan
gewoon op 1 tabhoogte telkens de checks doen

Dan hoef jij waarschijnlijk nooit complexe code te schrijven?

[Sc0tTy]

Erkens schreef op woensdag 31 maart 2010 @ 11:00:
[...]

Dan hoef jij waarschijnlijk nooit complexe code te schrijven?

mja vaak genoeg, maar als het niet hoeft doe ik het niet

[MBV]

Sc0tTy schreef op woensdag 31 maart 2010 @ 10:12:
mjah daar kan ik echt niet tegen, een functie waar veel geneste if/elses instaan
gewoon op 1 tabhoogte telkens de checks doen

C:

//had elke taal kunnen zijn
if (x > 5 && x < 10) {
  DoA();
  if (y > 10) {
    doX();
  }
  else {
    doY();
  }
}
else {
  doZ();
}

In welk opzicht wordt dat overzichtelijker door die op te splitsen? Ja, ik weet dat dat kan:

C:

//had elke taal kunnen zijn
if (x > 5 && x < 10 && y > 10) {
  DoA();
  doX();
}
else if (x > 5 && x < 10 && y < 10) {
  DoA();
  doY();
}
else {
  doZ();
}

Zeker als de conditie wat langer wordt is dat een heel onoverzichtelijke methode.

[ Voor 23% gewijzigd door MBV op 31-03-2010 13:43 ]

[Salandur]

MBV schreef op woensdag 31 maart 2010 @ 13:40:
[...]

C:

//had elke taal kunnen zijn
if (x > 5 && x < 10) {
  DoA();
  if (y > 10) {
    doX();
  }
  else {
    doY();
  }
}
else {
  doZ();
}

In welk opzicht wordt dat overzichtelijker door die op te splitsen? Ja, ik weet dat dat kan:

C:

//had elke taal kunnen zijn
if (x > 5 && x < 10 && y > 10) {
  DoA();
  doX();
}
else if (x > 5 && x < 10 && y < 10) {
  DoA();
  doY();
}
else {
  doZ();
}

Zeker als de conditie wat langer wordt is dat een heel onoverzichtelijke methode.

Omdat je nu de situatie y == 10 niet meeneemt

[HMS]

Salandur schreef op woensdag 31 maart 2010 @ 13:44:
[...]

Omdat je nu de situatie y == 10 niet meeneemt

Ja en x == 5 en x == 10 ook niet .

[Erkens]

HMS schreef op woensdag 31 maart 2010 @ 13:47:
[...]


Ja en x == 5 en x == 10 ook niet .

Zo zie je maar dat het veel onoverzichtelijker wordt als je if-statements niet wilt nesten

[mithras]

En dat bewijst maar eens dat nestings toch wat eenvoudiger zijn om te doorzien dan een gecomprimeerde platte structuur

edit:
lol

[ Voor 5% gewijzigd door mithras op 31-03-2010 13:56 ]

[Onbekend]

MBV schreef op woensdag 31 maart 2010 @ 13:40:
[...]

C:

//had elke taal kunnen zijn
if (x > 5 && x < 10) {
  DoA();
  if (y > 10) {
    doX();
  }
  else {
    doY();
  }
}
else {
  doZ();
}

In welk opzicht wordt dat overzichtelijker door die op te splitsen? Ja, ik weet dat dat kan:

C:

//had elke taal kunnen zijn
if (x > 5 && x < 10 && y > 10) {
  DoA();
  doX();
}
else if (x > 5 && x < 10 && y < 10) {
  DoA();
  doY();
}
else {
  doZ();
}

Zeker als de conditie wat langer wordt is dat een heel onoverzichtelijke methode.

Overzichtelijk maar in het eerste voorbeeld worden maximaal 3 vergelijkingen uitgevoerd terwijl in het tweede voorbeeld 6 vergelijkingen gemaakt worden.
Als je dit één keer doorloopt is dat niet zo erg, maar als je dat een miljoen keer doorloopt kies je toch wel voor de eerste oplossing.

[.oisyn]

Waar baseer je dat op? De meeste compilers snappen deze code wel, en zal een vergelijking maar 1 keer plaatsvinden.

.edit: VC++ 2008 SP1

code:

void noinline Work(int x, int y)
{
    if (x > 5 && x < 10 && y > 10) { 
004014F0  cmp         eax,5 
004014F3  jle         Work+25h (401515h) 
004014F5  cmp         eax,0Ah 
004014F8  jge         Work+25h (401515h) 
004014FA  cmp         ecx,0Ah 
004014FD  jle         Work+19h (401509h) 
        DoA(); 
004014FF  call        DoA (401330h) 
        DoX(); 
00401504  jmp         DoX (4013A0h) 
    } 
    else if (x > 5 && x < 10 && y < 10) { 
00401509  jge         Work+25h (401515h) 
        DoA(); 
0040150B  call        DoA (401330h) 
        DoY(); 
00401510  jmp         DoY (401410h) 
    } 
    else { 
        DoZ(); 
00401515  jmp         DoZ (401480h)

Het is duidelijk te zien dat de vergelijking x > 5 && x < 10 maar 1 keer wordt gedaan. Sterker nog, als je de structuur volgt dan zie je dat de compiler het vertaalt naar:

C++:

if (x > 5 && x < 10)
{
    if (y > 10)
    {
        DoA();
        DoX();
        return;
    }
    if (y < 10)
    {
        DoA();
        DoY();
        return;
    }
}
DoZ();

[ Voor 84% gewijzigd door .oisyn op 31-03-2010 14:10 ]

[MBV]

@.iosyn: we hadden het in eerste instantie over PHP

[edit]
Zou je hem kunnen aanpassen naar zoals ik hem bedoeld had? y <= 10 in het 2e geval? Benieuwd wat hij er dan van maakt

Salandur schreef op woensdag 31 maart 2010 @ 13:44:
[...]

Omdat je nu de situatie y == 10 niet meeneemt

Oeps Was om jullie te testen

HMS schreef op woensdag 31 maart 2010 @ 13:47:
[...]
Ja en x == 5 en x == 10 ook niet .

Dat heeft er niks mee te maken: dat is de else. De eerste 2 condities van de eerste 2 if-statements zijn identiek.

[ Voor 16% gewijzigd door MBV op 31-03-2010 14:12 ]

[Onbekend]

.oisyn schreef op woensdag 31 maart 2010 @ 13:59:
Waar baseer je dat op? De meeste compilers snappen deze code wel, en zal een vergelijking maar 1 keer plaatsvinden.

Op andere (oudere?) compilers.
Maar verder vind ik zelf voorbeeld 1 duidelijker, mits het iets anders opgeschreven is:

C:

//had elke taal kunnen zijn
if (x > 5 && x < 10) 
{
    DoA();

    if (y > 10)
        doX();
    else
        doY();
}
else
    doZ();

Maar dat is natuurlijk ieder voor zich.

[HMS]

MBV schreef op woensdag 31 maart 2010 @ 14:10:
@.iosyn: we hadden het in eerste instantie over PHP

[edit]
Zou je hem kunnen aanpassen naar zoals ik hem bedoeld had? y <= 10 in het 2e geval? Benieuwd wat hij er dan van maakt


[...]

Oeps Was om jullie te testen


[...]

Dat heeft er niks mee te maken: dat is de else. De eerste 2 condities van de eerste 2 if-statements zijn identiek.

Ja klopt, ik had niet goed gekeken . Ik had niet gezien dat in het 2e voorbeeld y == 10 een ander resultaat zou geven dan in het 1ste voorbeeld. My bad ;-)

[Davio]

Ach, je kunt ook teveel zeuren over het nesten.

Je moet per situatie gewoon kijken of het echt nodig is of niet, met C# kom ik bijvoorbeeld vaak de volgende situatie tegen in bijvoorbeeld een Click event van een button.

C#:

private void button_Click (object sender, EventArgs e)
{
  if (dialogForm.ShowDialog(this) == DialogResult.OK)
  {
    // Do Stuff
  } 
}

Ik maak er dan altijd dit van:

C#:

private void button_Click (object sender, EventArgs e)
{
  if (dialogForm.ShowDialog(this) != DialogResult.OK)
  {
    return;
  }
  
  // Do Stuff
}

[Alex)]

ReSharper stelt dat ook vaak voor ja. D'r zit wel wat in, al vind ik zelf een return midden in de code niet zo mooi.

[.oisyn]

Ik vind een return in het midden juist wel prettiger, omdat de early-out condities makkelijker te spotten zijn. Maar goed, smaken verschillen, zoals altijd .

MBV schreef op woensdag 31 maart 2010 @ 14:10:
@.iosyn: we hadden het in eerste instantie over PHP

Jij kwam anders met een C voorbeeld

Zou je hem kunnen aanpassen naar zoals ik hem bedoeld had? y <= 10 in het 2e geval? Benieuwd wat hij er dan van maakt

U vraagt ik draai:

code:

void noinline Work(int x, int y)
{
    if (x > 5 && x < 10 && y > 10) { 
004014F0  cmp         eax,5 
004014F3  jle         Work+23h (401513h) 
004014F5  cmp         eax,0Ah 
004014F8  jge         Work+23h (401513h) 
004014FA  cmp         ecx,0Ah 
004014FD  jle         Work+19h (401509h) 
        DoA(); 
004014FF  call        DoA (401330h) 
        DoX(); 
00401504  jmp         DoX (4013A0h) 
    } 
    else if (x > 5 && x < 10 && y <= 10) { 
        DoA(); 
00401509  call        DoA (401330h) 
        DoY(); 
0040150E  jmp         DoY (401410h) 
    } 
    else { 
        DoZ(); 
00401513  jmp         DoZ (401480h)

Dus:

C++:

if (x > 5 && x < 10) 
{ 
    if (y > 10) 
    { 
        DoA(); 
        DoX(); 
        return; 
    } 

    DoA(); 
    DoY(); 
    return;
} 
DoZ();

Ongeveer identiek aan je oorspronkelijke voorbeeld, behalve dat hij de DoA() niet buiten de binnenste if verhuist.

[ Voor 80% gewijzigd door .oisyn op 31-03-2010 15:10 ]

[HawVer]

Alex) schreef op woensdag 31 maart 2010 @ 15:04:
ReSharper stelt dat ook vaak voor ja. D'r zit wel wat in, al vind ik zelf een return midden in de code niet zo mooi.

Kwestie van smaak denk ik. In Windows Forms heb je methodes waar eerst een boel checks gedaan worden voordat je de code uitvoert. Als je dat binnen een if statement laat uitvoeren krijg je een enorme if of een diepe geneste if structuur. Dus kies ik voor de duidelijkheid vaak voor de if return. Als het maar netjes aan het begin van de functie gebeurd, zodat het duidelijk is dat het een verzameling checks is. Ik ben het wel met je eens dat je niet midden in je code teveel dan dit soort returns wilt hebben.

[Woy]

Alex) schreef op woensdag 31 maart 2010 @ 15:04:
ReSharper stelt dat ook vaak voor ja. D'r zit wel wat in, al vind ik zelf een return midden in de code niet zo mooi.

Ik vind het meestal ook niet mooi als je te veel return plekken hebt in je code, maar zeker voor het checken van pre-condities en early out condities vind ik het wel duidelijk.

[MBV]

Davio schreef op woensdag 31 maart 2010 @ 14:47:
Je moet per situatie gewoon kijken of het echt nodig is of niet, met C# kom ik bijvoorbeeld vaak de volgende situatie tegen in bijvoorbeeld een Click event van een button.

[knip]

Ik maak er dan altijd dit van:

C#:

private void button_Click (object sender, EventArgs e)
{
  if (dialogForm.ShowDialog(this) != DialogResult.OK)
  {
    return;
  }
  
  // Do Stuff
}

Wat doe je dan zodra je ook iets met DialogResult.CANCEL moet doen? Ik snap het principe van assert-achtige checks voor je de functie echt ingaat, maar dit voorbeeld vind ik niet echt sterk.

[Haan]

MBV schreef op woensdag 31 maart 2010 @ 16:42:
[...]

Wat doe je dan zodra je ook iets met DialogResult.CANCEL moet doen? Ik snap het principe van assert-achtige checks voor je de functie echt ingaat, maar dit voorbeeld vind ik niet echt sterk.

Maakt dat wat uit dan? Blijkbaar moet er in dit voorbeeld alleen code uitgevoerd worden als er op OK is geklikt, wat boeit die cancel dan? En wil je er later wel rekening mee houden pas je gewoon de code aan

[BarôZZa]

De code bij een cancel kan je dan eventueel nog voor die return zetten

Maar zelf zou ik niet zien waarom je zou checken of het DialogResult GEEN ok geeft.

Ik zou dan dit logischer vinden:

C#:

private void button_Click (object sender, EventArgs e) 
{ 
  if (dialogForm.ShowDialog(this) == DialogResult.OK) 
  { 
  // Do Stuff 
  } 
   
}

Edit: Spuit 11, ik moet eens verder teruglezen. Hij verandert dus juist de bovenstaande code.

Edit 2: ik bedenk me nu dat ik zelf ook wel eens van die constructie gebruik maak

PHP:

if(!$currentUser->isLoggedIn()){
  include "login.php";
  exit;
}
// do stuff

[ Voor 28% gewijzigd door BarôZZa op 31-03-2010 17:53 ]

[Olaf van der Spek]

MBV schreef op woensdag 31 maart 2010 @ 16:42:
Ik snap het principe van assert-achtige checks voor je de functie echt ingaat, maar dit voorbeeld vind ik niet echt sterk.

Ik gebruik zo'n constructie ook vaak. Het is korter en de code is simpeler.

[jip_86]

Hier lijkt het niet heel nuttig, maar als '//do work' een lap code is waar ook al drie keer ingesprongen is scheelt die extra keer inspringen toch wel een stuk schermruimte.

[MBV]

Daarom zei ik ook: "Ik snap het principe van assert-achtige checks voor je de functie echt ingaat, maar dit voorbeeld vind ik niet echt sterk.". In dit geval is het een event-handler die iets moet doen als je een OK krijgt. Als do_work dan 5x inspringt, moet je er een functie van maken die je wat mij part handle_ok(sender) noemt. null-checks, sanity-checks etc (java...) doe ik ook aan het begin van de functie, en return (of gooi een InvalidArgumentException/InvalidStateException) als het me niet bevalt.

[Olaf van der Spek]

MBV schreef op woensdag 31 maart 2010 @ 20:29:
Als do_work dan 5x inspringt, moet je er een functie van maken die je wat mij part handle_ok(sender) noemt.

Waarom? Functies gebruik ik vooral als ze meerdere keren worden aangeroepen. Anders is het een beetje onnodig.

[brama]

Alex) schreef op woensdag 31 maart 2010 @ 15:04:
ReSharper stelt dat ook vaak voor ja. D'r zit wel wat in, al vind ik zelf een return midden in de code niet zo mooi.

Ik vind dat je dat niet zo kunt zeggen in het algemeen. Een algemene stelregel kan wel zijn dat je zoveel mogelijk probeert te beperken dat je op meerdere plaatsen in een functie gaat retourneren (of breaken in loops). Maar dat moet je dan weer niet te ver gaan doortrekken en het daarom maar *altijd* gaan doen. In dit geval vind ik die early return bijvoorbeeld zeer terecht, omdat het onnodig genest tegengaat. Een mooie compromis.

De 'goto' regel is er ook zo eentje. Nee, die hoor je praktisch nooit nodig te hebben, maar in het volgende hypothetische voorbeeld gebruik ik liever de 2e variant:

C:

void function() {
  char *foo = (char*)malloc(1024);
  int result = 0;

  // ..

  if (condition) {
    if (other) {
      result = -1;
    } 
  }

  if (result != -1) {

    //..

    if (bad_stuff) {
      result = -1;
    }

    if (result != -1) {
      // ...
    }
  }

  // ..

  free(foo);
  return result;
}

Typisch voorbeeld van code waar je overal die rottige check op result moet doen indien er ergens iets misgegaan is, maar je wel nog op het einde van de functie moet uitkomen om de lokale variabelen te kunnen vrijgegen als je geen memory leaks wil. Duidelijk hypothetisch, aangezien je het vaak wel kunt voorkomen met wat refactoren, maar in sommige gevallen maakt dat het er niet beter op.

In dat soort uitzonderingen zou je best nog wel een goto-achtige constructie kunnen gebruiken, en wat je dan ook vaak ziet in C is dat ze grote blokken code voorzien van een do { ... } while (0); zodat je halverwege dat blok met een break eruit kunt springen. Wat niet meer is dan een veredelde goto:

C:

  char *foo = (char*)malloc(1024);
  int result = 0;

  // ..

  do {
    if (condition) {
      if (other) {
        result = -1;
        break;
      } 
    }

    if (bad_stuff) {
      result = -1;
      break;
    }

    // ...
  } while (0);

  //..

  free(foo);
  return result;
}

[user109731]

Olaf van der Spek schreef op woensdag 31 maart 2010 @ 20:46:
[...]

Waarom? Functies gebruik ik vooral als ze meerdere keren worden aangeroepen. Anders is het een beetje onnodig.

Ik verplaats anders best vaak stukken code naar een losse functie, ook al wordt het maar 1 keer aangeroepen. Een voorbeeldje van vandaag:

Java:

void paint(Graphics g) 
{
  // ...
  paintFoo(g);
  paintBar(g);
}

Het had allemaal in paint() gekund, maar vaak vind ik zoiets dan duidelijker. Vooral handig bij ingewikkelde of diep-geneste code, waar MBV vanuit ging.

Ik zie trouwens net dat GCC dit:

C:

if(x > 5 && x < 10) {}

Compileert naar zoiets:

C:

x -= 6;
if(x > 3) goto ..; // unsigned compare

Verzin dat zelf maar

[ Voor 4% gewijzigd door user109731 op 31-03-2010 21:24 ]

[Alex)]

JanDM schreef op woensdag 31 maart 2010 @ 21:19:
Ik zie trouwens net dat GCC dit:

C:

if(x > 5 && x < 10) {}

Compileert naar zoiets:

C:

x -= 6;
if(x > 3) goto ..; // unsigned compare

Verzin dat zelf maar

Jamaar, dat krijgt op die manier een hele andere betekenis toch? Als x nu 54 is, wordt hij in de 1e code niet uitgevoerd (groter dan 5, maar niet kleiner dan 10), maar in de tweede wel (groter dan 3)

[Verwijderd]

voor diegene onder ons die bekend zijn met assemblier is dat wel degelijk bekend

in asm kan je namelijk maar 1 compare (flags enzo..) per regel gebruiken, dan heb je dus dit nodig:

C:

if (x > 5) 
 if (x < 10) {...}

ik kan je nu al vertellen dat meer is dan 3 regels (een substract, een compare, en een conditionele jump) van jouw voorbeeld.
als je het geluk hebt dat je 2 waarden powers of 2 zijn kan het ook in een keer met een AND.

dat doet me denken dat ik nog een keer fatsoenlijk x86 asm moet gaan leren, of x64 misschien...

JanDM schreef op woensdag 31 maart 2010 @ 21:19:
[...]

Ik verplaats anders best vaak stukken code naar een losse functie, ook al wordt het maar 1 keer aangeroepen. Een voorbeeldje van vandaag:

idem, een main() met enkel 30 functieaanroepen en een loop is een stuk duidelijker dan diezelfde lap code zonder functies.
dan snap je echt geen reet meer van de flow van je programma.

[ Voor 29% gewijzigd door Verwijderd op 31-03-2010 21:43 ]

[Matis]

Dat is ook de reden dat je or-statement van links naar rechts geëvalueerd wordt en dus wel degelijk uit kan maken in de performance.

[user109731]

Alex) schreef op woensdag 31 maart 2010 @ 21:38:
[...]

Jamaar, dat krijgt op die manier een hele andere betekenis toch? Als x nu 54 is, wordt hij in de 1e code niet uitgevoerd (groter dan 5, maar niet kleiner dan 10), maar in de tweede wel (groter dan 3)

Hij draait de conditie om, met de goto ..; spring je naar de else. Ik had misschien beter dit kunnen geven:

C:

x -= 6;
if(x <= 3) {}

[RayNbow]

JanDM schreef op woensdag 31 maart 2010 @ 21:19:
[...]

Ik verplaats anders best vaak stukken code naar een losse functie, ook al wordt het maar 1 keer aangeroepen. Een voorbeeldje van vandaag:

Java:

void paint(Graphics g) 
{
  // ...
  paintFoo(g);
  paintBar(g);
}

Het had allemaal in paint() gekund, maar vaak vind ik zoiets dan duidelijker. Vooral handig bij ingewikkelde of diep-geneste code, waar MBV vanuit ging.

Ah, de bekende Extract Method

[Verwijderd]

JanDM schreef op woensdag 31 maart 2010 @ 21:42:
[...]

Hij draait de conditie om, met de goto ..; spring je naar de else. Ik had misschien beter dit kunnen geven:

C:

x -= 6;
if(x <= 3) {}

neem (x <= 3) met x = -2, dan doet de compiler 2 - 3, en vervolgens kijkt hij of de sign bit is veranderd (== carry) vervolgens doet hij een jump-if-carry, of wat de syntax daarvoor ook is
1111 1110 (-2)
0000 0011 (3)
------------------
1111 1011

andwoord: de carry is niet geset, dus de expressie (-2 <= 3) is false

om diezelfde reden heeft het soms geen zin om de volgende expressie te testen met crappy 8 bit compilers:

C:

(x < 0) //altijd false

of sla ik de plank nu grandioos mis?

[MBV]

Olaf van der Spek schreef op woensdag 31 maart 2010 @ 20:46:
[...]

Waarom? Functies gebruik ik vooral als ze meerdere keren worden aangeroepen. Anders is het een beetje onnodig.

Ik heb het toch al meerdere keren gedaan, om een paar redenen:
- functies moeten 1 ding doen. Ik heb vaak een functie die uitvist wat er gedaan moet worden, en dan meerdere andere functies aanroept zodra datgene wat gedaan moet worden niet meer op 5 regels past
- functies moeten in principe op je scherm passen. Als dat niet meer lukt, moet je ze opsplitsen. Zie ook de vorige regel.
- meer dan 5 niveaus nesten is slecht voor bug-hunten

Ik heb een keer een backup-methode moeten uitzoeken die bestond uit 1000 regels binnen een while-loop, met daarin weer andere while-loops enzovoort. Opgesplitst in 5 foreach-loops die een functie aanriepen in de trend van getData($id), storeData($id) enzovoort. Dat was nogal een klus: de verschillende taken stonden namelijk redelijk willekeurig door elkaar. * MBV hoopt voor de huidige ontwikkelaars dat binnenkort echt de website uit de lucht wordt gehaald, en vervangen door de nieuwe Ik heb wel wat opgeruimd, maar het hele systeem was flawed by design.

[ Voor 3% gewijzigd door MBV op 31-03-2010 21:58 ]

[Olaf van der Spek]

MBV schreef op woensdag 31 maart 2010 @ 21:57:
Ik heb het toch al meerdere keren gedaan, om een paar redenen:
- functies moeten 1 ding doen. Ik heb vaak een functie die uitvist wat er gedaan moet worden, en dan meerdere andere functies aanroept zodra datgene wat gedaan moet worden niet meer op 5 regels past
- functies moeten in principe op je scherm passen. Als dat niet meer lukt, moet je ze opsplitsen. Zie ook de vorige regel.
- meer dan 5 niveaus nesten is slecht voor bug-hunten

Daar heb je gelijk in. Maar dan nog zou ik gaan voor de if (OK != ...) return variant en niet voor een nieuwe functie in dit geval.

[Davio]

Olaf van der Spek schreef op woensdag 31 maart 2010 @ 19:36:
[...]

Ik gebruik zo'n constructie ook vaak. Het is korter en de code is simpeler.

Laat ik mezelf maar even verduidelijken dan.

Ik gebruik die if-return constructies vaak als er meerdere checks plaatsvinden waarvan er maar één hoeft te falen om te cancellen of in events die alleen maar een extra form openen, zoals in mijn voorgaande post.

C#:

private void ButtonOK_Click (..)
{
  if (string.IsNullOrEmpty(this.textBoxWhatever.Text))
  {
    this.errorProvider.SetError(this.textBoxWhatever, "Whatever is leeg.");
    return;
  }
  if (this.textBoxWhatever.Text.Length < 6)
  {
    this.errorProvider.SetError(this.textBoxWhatever, "Whatever moet uit minimaal zes karakters bestaan.");
    return;
  }
  // etc etc
  // en dan op het eind:
  this.DialogResult = DialogResult.OK;
  // dit vind ik vaak beter dan standaard DialogResult.OK toewijzen aan de button en dan elke keer this.DialogResult = DialogResult.none moeten zetten in de if-returns.
}

[Davio]

JanDM schreef op woensdag 31 maart 2010 @ 21:19:
[...]

Ik verplaats anders best vaak stukken code naar een losse functie, ook al wordt het maar 1 keer aangeroepen. Een voorbeeldje van vandaag:

Java:

void paint(Graphics g) 
{
  // ...
  paintFoo(g);
  paintBar(g);
}

[..]

Ik ben het daar wel redelijk mee eens. Voordeel is namelijk dat je dan ook weer logische namen kan geven aan je methodes zodat duidelijker is wat er gebeurt. En logische namen geven is wel iets wat je na zoveel jaar aanleert, aan string s en int i heeft niemand wat en Hungarian notation is ook weer dubieus.

In jouw voorbeeld bijvoorbeeld paintCircle en paintText of zo.

[Jaap-Jan]

Davio schreef op woensdag 31 maart 2010 @ 23:22:
[...]

Ik ben het daar wel redelijk mee eens. Voordeel is namelijk dat je dan ook weer logische namen kan geven aan je methodes zodat duidelijker is wat er gebeurt. En logische namen geven is wel iets wat je na zoveel jaar aanleert, aan string s en int i heeft niemand wat en Hungarian notation is ook weer dubieus.

In jouw voorbeeld bijvoorbeeld paintCircle en paintText of zo.

Hungarian notation, mits goed gebruikt, zorgt ook voor duidelijkheid in de code. Joel Spolsky heeft er wat over geschreven: Making Wrong Code Look Wrong en ook Steve McConnell (schrijver van 'Code Complete') wijdt een stuk aan de voordelen van Hungarian notation.

Ik ben net aan het lezen in Code Complete en veel van de zaken die op de laatste pagina langs zijn gekomen passeren ook in dat boek de revue, dus feest van herkenning. Bijvoorbeeld het groeperen van statements die bij elkaar horen en eventueel refactoren naar een nieuwe routine om de bedoeling duidelijk te maken. Echt een aanrader.

[Davio]

Ja, maar afschaffing van Hungarian notation zorgt ook weer voor encapsulation.

Stel nou in jouw geval dat je een int hebt genaamd 'iCustomerID'. Maar dan blijkt dat je een unsigned int wilt gebruiken en ga je hem weer hernoemen naar 'uiCustomerID'. Is het dan niet gewoon beter om voor 'CustomerID' te kiezen?

En voor sommige klassen is het ook niet handig ze zo af te korten, bijvoorbeeld een UserLoginForm zou dan ulfLogin worden? Nee, je moet er erg mee oppassen en ik gebruik het liever niet, zorgt er bij mij voor dat ik een soort verplicht wordt om duidelijkere namen te gebruiken voor mijn variabelen.

[kenneth]

Davio schreef op donderdag 01 april 2010 @ 09:19:
Ja, maar afschaffing van Hungarian notation zorgt ook weer voor encapsulation.

Stel nou in jouw geval dat je een int hebt genaamd 'iCustomerID'. Maar dan blijkt dat je een unsigned int wilt gebruiken en ga je hem weer hernoemen naar 'uiCustomerID'. Is het dan niet gewoon beter om voor 'CustomerID' te kiezen?

Dat is niet wat Hungarian notation oorspronkelijk is. Dat is wel wat het is geworden. Lees het artikel van Spolsky maar (let wel: Spolsky-alert).

Ik ben er ook geen fan van trouwens.

[ Voor 5% gewijzigd door kenneth op 01-04-2010 09:24 ]

[Davio]

Ik heb het artikel gelezen en ik snap nu waar het over gaat.

Hungarian was dus oorspronkelijk bedoel om aan te geven wat voor soort variabele iets is en niet zozeer wat voor type.

Het gaat er dus niet om te zeggen dat iets een string is, maar wat voor soort string het is. Daardoor zou het sporadisch gebruikt moeten worden en niet standaard als afkorting aan het begin van elke variabele.

[bat266]

Nog even over toevoegen van functies. Ook in het boek clean code zegt Robert C. Martin dat je er veelvuldig gebruik van moet maken. Met name met de reden dat code vaker gelezen dan geschreven wordt en het met nuttige namen veel duidelijker van wordt. Boek is echt een aanrader. Veel goede logische tips als je erover nadenkt.

[ Voor 3% gewijzigd door bat266 op 01-04-2010 11:51 ]

[YopY]

bat266 schreef op donderdag 01 april 2010 @ 11:50:
Veel goede logische tips als je erover nadenkt.

Als je er over nadenkt, ja, . Dat is eigenlijk ook de reden waarom er 'vieze' code bestaat - er wordt niet, niet genoeg, of verkeerd over nagedacht. Vaak ivm deadlines, geen geduld, of geen mensen (met kennis) waar je het erover kunt hebben. Daarom vindt ik ook dat je altijd in een team moet kunnen programmeren, waar iedereen met iedereen zijn code moet gaan werken of op z'n minst moet gaan nakijken.

Kost wel meer (geld + tijd), maar dan heb je wel schone code en zie je je eigen code na een paar jaar niet in dit topic terug, danwel dat er veel tijd besteed wordt in het uitzoeken + repareren van oude code.

[Davio]

YopY schreef op donderdag 01 april 2010 @ 11:56:
[...]


Als je er over nadenkt, ja, . Dat is eigenlijk ook de reden waarom er 'vieze' code bestaat - er wordt niet, niet genoeg, of verkeerd over nagedacht. Vaak ivm deadlines, geen geduld, of geen mensen (met kennis) waar je het erover kunt hebben. Daarom vindt ik ook dat je altijd in een team moet kunnen programmeren, waar iedereen met iedereen zijn code moet gaan werken of op z'n minst moet gaan nakijken.

Kost wel meer (geld + tijd), maar dan heb je wel schone code en zie je je eigen code na een paar jaar niet in dit topic terug, danwel dat er veel tijd besteed wordt in het uitzoeken + repareren van oude code.

Ja, het is vaak een kwestie van korte termijn versus lange termijn en het gebrek aan in de toekomst kunnen kijken.

Hierdoor wordt er te vaak een ad-hoc oplossing bedacht en geïmplementeerd die heel specifiek is en alleen voor het ontstane probleem werkt. Als het probleem dan algemener wordt, begint het gezeur. Moet je weer op 10 plaatsen iets veranderen.

En hoe langer zoiets aan de gang is, hoe erger het wordt. Ik werk met een collega samen aan software van meer dan 10 jaar oud en het is echt een hel om met die spaghetti te werken.

Goed programmeren vergt gewoon veel geduld, vooral bij personen die minder technisch zijn, omdat het lang duurt voor je echt iets tastbaars kunt laten zien. Die snappen niet dat je weken nodig hebt om een gedegen framework te bouwen voor die extra functionaliteit waar ze over 2 jaar om zullen vragen.

[bat266]

Achja heb wel eens meegemaakt. Bug in productie met een hotfix fixen. Duidelijk tegen managers aangeven deze code is zo slecht it should be removed en moet er een design fix komen in next release. Managers roepen niet belangrijk niet nodig werkt toch. Nogmaals aangegeven dit gaat problemen opleveren we need design fix. 4 maanden later klapt de boel eruit op de hotfixt, althans zelfde piece of code. Ik was al gemoved naar ander project dus mocht het niet fixen. Heb daar uren over gebeld hoe het te fixen was (ook toen al een voorzet gegeven en gedocumenteerd maar dat was verdwenen). Heeft uiteindelijk minstens 2x zo veel gekost dan dat ik het at that moment at that place had mogen fixen in de dev branch for next release. Maja Project managers wat heb je eraan

[Davio]

Soms zijn project managers wel handig als je in Mickey Mouse-taal moet vertellen waar je mee bezig bent, want dat helpt jezelf dan ook om abstracte ideeën te simplificeren en concreter te maken wat er precies moet gebeuren, maar dat voordeel is op andere momenten ook weer een groot nadeel, vooral als er niet geluisterd wordt naar de ervaring van de developer.

[Laurens-R]

hmmm ben zojuist 29x de volgende constructie in de broncode van een oude app tegengekomen.

code:

if(true)
{
    //wat code
    if (true)
    {
        //etc
    }

}

beloofd niet veel goeds voor de rest van code

[Crazy D]

Davio schreef op donderdag 01 april 2010 @ 12:04:
Goed programmeren vergt gewoon veel geduld, vooral bij personen die minder technisch zijn, omdat het lang duurt voor je echt iets tastbaars kunt laten zien. Die snappen niet dat je weken nodig hebt om een gedegen framework te bouwen voor die extra functionaliteit waar ze over 2 jaar om zullen vragen.

Het is niet altijd te verdedigen dat een klant 50.000 extra moet betalen zodat er iets staat wat wellicht misschien eventueel ooit in de toekomst zichzelf terugverdient doordat je dan sneller je aanpassingen kunt doorvoeren. Eventueel. Wellicht. Oftewel je zult altijd een afweging moeten maken tussen technisch de mooiste oplossing en de meest realistische oplossing zodat het product op tijd af is, binnen budget, en weinig bugs bevat (hoewel dat laatste natuurlijk altijd de goal zou moeten zijn ).

Ik heb genoeg code opgeleverd die in dit topic past, maar ik heb ook meer dan genoeg klanten die er dolgelukkig mee zijn want die hebben precies de oplossing die ze nu willen, voor een redelijke prijs. En die hele enkele keer dat we onszelf in de vingers hebben gesneden omdat de gekozen oplossing niet de meest uitbreidbare bleek te zijn, is op 1 vinger te tellen.... het is in ieder geval bij de klanten waar ik mee te maken heb, beter te verkopen als ik over 2 jaar 2 weken extra bezig ben met een uitbreiding die zij op dat moment willen hebben, dan dat ik dat nu ben voor iets wat wellicht nooit een issue is (en bij veel wat wij hebben gemaakt zijn ook niet of nauwelijks aanpassingen nodig geweest).

(1 en ander hangt dus ook uiteraard af van het soort ontwikkeling wat je doet, als jij het framework moet bouwen waar je bedrijf bovenop ontwikkeld is het een ander verhaal...)


Oh die if (true) constructies ben ik ook nog weleens tegengekomen, verdraait handige manier om even stukjes code aan of uit te zetten (if (false...) en het dan vervolgens compleet vergeten uit de code te halen

[Sc0tTy]

ik gebruik zelf nooit i/s/b/etc als eerste char van var namen, vind het irritant werken wanneer ik de variabele wil aanspreken + het is in de meeste IDE's onnodig aangezien zij de type's netjes weergeven.

wat ik wel altijd doe is lijsten in meervoud zetten dus
String naam; en String[] namen;
in oude code van mezelf zie ik nog wel eens arrNaam voorbij komen, gelukkig ben ik daar van af gestapt.

[Alex)]

Dat doe ik ook, maar ik probeer zoveel mogelijk Engelstalige benamingen aan te houden. Ook methods en comments geef ik Engelstalige signatures.

[Davio]

@Crazy D

Wat is het toch jammer dat we niet in een perfecte maatschappij leven waarbij tijd en geld oneindig zijn en je dus altijd de meest elegante oplossing af kunt leveren.

Ik zie mijn stukjes code ook te vaak als mijn 'kindjes' en die maak ik niet graag vies. Toch leert programmeren binnen een bedrijf in plaats van als hobby je wel dat je dingen los moet kunnen laten en ook met een sub-optimale oplossing tevreden moet kunnen zijn.

Edoch kan ik het niet laten collega's te wijzen op maniertjes om 0,000001% processor rekenkracht te besparen.

Hier nog even een vraag die hier lichtjes verband mee houdt, maakt een compiler van deze methodes dezelfde soep of is de één tig keer sneller dan de ander?

C#:

private bool isEvenModTwo (int numToTest)
{
  return numToTest % 2 == 0;
}

private bool isEvenBitwise (int numToTest)
{
  return (numToTest & 1) == 0;
}

[Sebazzz]

Crazy D schreef op donderdag 01 april 2010 @ 14:23:
[...]

Oh die if (true) constructies ben ik ook nog weleens tegengekomen, verdraait handige manier om even stukjes code aan of uit te zetten (if (false...) en het dan vervolgens compleet vergeten uit de code te halen

Hehe, ik niet. Ik heb standaard al mijn projecten op 'treat warnings as errors' staan.

[Haan]

Davio schreef op donderdag 01 april 2010 @ 15:24:
@Crazy D

Hier nog even een vraag die hier lichtjes verband mee houdt, maakt een compiler van deze methodes dezelfde soep of is de één tig keer sneller dan de ander?

C#:

private bool isEvenModTwo (int numToTest)
{
  return numToTest % 2 == 0;
}

private bool isEvenBitwise (int numToTest)
{
  return numToTest & 1 == 0;
}

Wil je dit nou zelf weten, of is het een vraag aan ons? In ieder geval compiled dit niet: numToTest & 1 == 0 (Operator '&' cannot be applied to operands of type 'int' and 'bool')

Fixed: (numToTest & 1) == 0

IL:

code:

IL_0000:  nop
  IL_0001:  ldarg.0
  IL_0002:  ldc.i4.2
  IL_0003:  rem
  IL_0004:  ldc.i4.0
  IL_0005:  ceq
  IL_0007:  stloc.0
  IL_0008:  br.s       IL_000a
  IL_000a:  ldloc.0
  IL_000b:  ret
} // end of method Program::isEvenModTwo

code:

IL_0000:  nop
  IL_0001:  ldarg.0
  IL_0002:  ldc.i4.1
  IL_0003:  and
  IL_0004:  ldc.i4.0
  IL_0005:  ceq
  IL_0007:  stloc.0
  IL_0008:  br.s       IL_000a
  IL_000a:  ldloc.0
  IL_000b:  ret
} // end of method Program::isEvenBitwise

Verschil is dus minimaal, ik heb zelf geen flauw idee wat het uitmaakt

[ Voor 33% gewijzigd door Haan op 01-04-2010 15:47 ]

[Laurens-R]

code:

 return (numToTest & 1) == 0;

zo doettie het wel haakjes doen wonderen. edit ah... hierboven is dat ook al geconstateerd.

huh wtf??? Komt er een lemming naar beneden denderen over m'n browser terwijl ik dit intik LOL

nog een 1 april verassing tweakers ?

[ Voor 23% gewijzigd door Laurens-R op 01-04-2010 15:52 ]

[Davio]

Het was een serieuze vraag, ik zie namelijk wel eens beweringen dat een bitwise comparison om te checken of een getal even is, sneller is dan gewoon % 2. Ik vroeg me af of hier een kern van waarheid in zat of dat een goede compiler % 2 == 0 vertaalt naar een eigen bitwise check.

En die fix is inderdaad nodig, zal het origineel bewerken.

[Bob]

Dat is intermediate code die daar weergegeven is? Dan denk ik dat de just in time compiler het nog wel omzet naar het goedkoopste, intuïtief bitwise, maar misschien kost een integer deling evenveel cycles, dat zou je eens moeten opzoeken.

In C krijg je alleszins voor unsigned integer delingen en remainders voor zover mogelijk steeds bitwise instructies, heb ik eens getest.

[Davio]

Ik heb het een aantal keer getest met een loopje van 0 - 1000000000 en bitwise was ongeveer 8% sneller.

[Olaf van der Spek]

Voor oneven zie ik wel eens % 2 == 1 voorbij komen, maar dat werkt niet (altijd) voor negatieve getallen.

[ValHallASW]

http://www.zedshaw.com/essays/programmer_stats.html

[fleppuhstein]

Olaf van der Spek schreef op donderdag 01 april 2010 @ 17:20:
Voor oneven zie ik wel eens % 2 == 1 voorbij komen, maar dat werkt niet (altijd) voor negatieve getallen.

Eigenlijk is

code:

% 2

wel een "zwaardere" belasting dan

code:

& 1

(Check op first bit, die al gelijk even/oneven aangeeft)

[Jaap-Jan]

Olaf van der Spek schreef op donderdag 01 april 2010 @ 17:20:
Voor oneven zie ik wel eens % 2 == 1 voorbij komen, maar dat werkt niet (altijd) voor negatieve getallen.

Ik kan niet bedenken wanneer niet. -1 in 8-bit two's complement is 1111 11111, -2 is 1111 1110. En zo gaat het gewoon door, tot -127 (1000 0001) en -128 (1000 0000).

[ Voor 73% gewijzigd door Jaap-Jan op 01-04-2010 17:44 ]

[RayNbow]

ghci> import Test.QuickCheck
ghci> import Data.Bits
ghci> test $ \x -> even x == (x .&. 1 == 0)
OK, passed 100 tests.

Edit: en als we extra paranoide zijn kunnen we de eigenschap ook nog alleen voor negatieve waarden testen:

ghci> test $ \x -> x < 0 ==> even x == (x .&. 1 == 0)
OK, passed 100 tests.

[ Voor 43% gewijzigd door RayNbow op 01-04-2010 17:50 ]

[Olaf van der Spek]

Jaap-Jan schreef op donderdag 01 april 2010 @ 17:40:
[...]
Ik kan niet bedenken wanneer niet. -1 in 8-bit two's complement is 1111 11111, -2 is 1111 1110. En zo gaat het gewoon door, tot -127 (1000 0001) en -128 (1000 0000).

Omdat (vaak) -1 % 2 == -1 en dus niet 1...

[Verwijderd]

of gewoon..

C:

if (foo << (sizeof(foo)*8-1))
 { //oneven; 
 }

op de 8080 kan je gewoon een right shift doen, en dan carry checken, maar dat kan met C dacht ik niet (shifts zijn een van de weinige dingen die niet in C zitten, anthans, niet allemaal)

edit: weet iemand waarom het volgende zeer verneukte resultaten geeft?

C:

#include <stdio.h>
#include <time.h>

int shift(int b) {
    return (b << (sizeof(b)*8-1));
}


main() {
    unsigned int time;
    
    for(int j=0; j < 100; j++) {
        time = clock();
        for(unsigned i = 0; i < 1000000; i++)
            shift(i);
        time = clock() - time;
        printf("%u\t", time);
    }
}

dat hij 1 niet 1 ms is boeit mij niet, als hij maar constant is
hij print soms allemaal 12 en 13'tjes, en daarna weer een reeks 5-jes
sample output:

code:

12      12      12      17      12      12      12      13      12      12
12      17      13      12      12      10      6       5       6       6
6       6       6       9       6       6       6       6       6       6
6       6       6       6       6       6       6       6       18      6
6       6       6       6       6       5       4       4       4       4
4       4       4       4       4       4       4       4       4       4
4       4       4       4       4       4       4       4       4       5
4       4       4       4       4       3       4       4       4       4
4       4       4       4       4       4       4       4       5       4
4       4       4       5       4       4       4       4       4       4

edit:
met << en & doet mijn code er 12800 "units" over, met % 8300
x % 2 is dus duidelijk sneller met mijn compiler (mingw, vrij recente versie)

nog een edit: wacht eens, eigelijk slaat dat helemaal nergens op
hoe doe je immers modulo een macht van 2?
juist, met de trage AND

[ Voor 78% gewijzigd door Verwijderd op 01-04-2010 19:53 ]

[MBV]

MinGW? Dan zit je op windows, die een nogal onnauwkeurige klok heeft. 'Misschien' ligt het daaraan

[Paul]

Verwijderd schreef op donderdag 01 april 2010 @ 18:05:
edit: weet iemand waarom het volgende zeer verneukte resultaten geeft?

Ik gok vanwege de multitasking van je OS, dat je thread niet continue draait maar af en toe plaats moet maken voor een andere thread

[Davio]

Laat ik zelf nog een inzicht toevoegen over %2 versus &1 die ik bij nader onderzoek heb verkregen:

Als je &1 gebruikt, neem je iets aan over de representatie van integers door het systeem, namelijk dat ze als laatste bit altijd een 0 hebben. Je moet altijd oppassen met aannames te doen over het onderliggende systeem. Ik begreep dat dit voor negatieve integers niet altijd waar is?

Als je %2 gebruikt, zit je erg dicht bij de wiskundige beschrijving van een "even getal", namelijk dat het deelbaar is door 2 (zonder rest).

Ik kan me voorstellen dat vroeger vaak voor de eerste variant gekozen werd in een tijd dat compilers nog niet erg slim waren en veel programmeertalen sowieso erg op machinetaal leken.

Nu kan je echter aannemen dat veel compilers snappen wat ze met %2 aanmoeten en laat ik liever die 8% performance winst liggen ten bate van leesbaarheid en een duidelijkere modellering van de werkelijkheid.

Zo'n check zal ook zelden de bottleneck van een programma zijn.

[RayNbow]

Davio schreef op donderdag 01 april 2010 @ 22:09:
Als je &1 gebruikt, neem je iets aan over de representatie van integers door het systeem, namelijk dat ze als laatste bit altijd een 0 hebben. Je moet altijd oppassen met aannames te doen over het onderliggende systeem.

Correct, aangezien & hier een operatie op de bits is en dus de representatie.

Ik begreep dat dit voor negatieve integers niet altijd waar is?

Voor de meest gangbare representatie voor integers ([url=http://en.wikipedia.org/wiki/Two's_complement]2's complement[/]) geldt wel dat de laatste bit aangeeft of het getal even (0) of oneven (1) is. Zie ook de testbare eigenschap in mijn eerdere post.

[...]Zo'n check zal ook zelden de bottleneck van een programma zijn.

Meten is weten. Pas nooit voortijdige optimalisaties toe.

[Verwijderd]

Paul Nieuwkamp schreef op donderdag 01 april 2010 @ 20:05:
[...]

Ik gok vanwege de multitasking van je OS, dat je thread niet continue draait maar af en toe plaats moet maken voor een andere thread

volgens mijn bron berekent die functie echter de tijd die de thread heeft gedraaid sinds de start van het programma...

maargoed, het zal windows wel zijn.

[iH8]

http://framework.zend.com.../library/Zend/Version.php

[Michali]

iH8 schreef op vrijdag 02 april 2010 @ 09:10:
http://framework.zend.com.../library/Zend/Version.php

Whoops, vergeten bij te werken.

[Haan]

Wat is er zo grappig?

[roy-t]

Haan schreef op vrijdag 02 april 2010 @ 09:24:
Wat is er zo grappig?

De link gaat naar release 'release-1.10.3' maar in het bestand staat een constant string om de versie op te vragen die nog 1.10.2 weergeeft.

[mithras]

Haan schreef op vrijdag 02 april 2010 @ 09:24:
Wat is er zo grappig?

ZF 1.10.3 heeft een Zend_Version class met Zend_Version::VERSION nog steeds op 1.10.2. Foutje van een van de developers die het vergeten is bij te werken. Het is nu al snel opgemerkt dus het zak vandaag nog wel gefixed worden

[roy-t]

Wat betreft slechte programmeer voorbeelden: ik flik nog wel eens het volgende truukje:

C#:

if(someHardCondition && someOtherLongCondition)
{
     return true;
}

return false;

Dan ben ik zo bezig met die check schrijven dat ik helemaal vergeet dat ik die check meteen kan returnen ala:

C#:

return someHardCondition && someOtherLongCondition

Wordt er redelijk vaak op gewezen als ik even snel een voorbeeld stukje code schrijf ofzo. Erg stom, maar gelukkig werkt het programma nog net zo goed.