[alg] slechtste prog voorbeelden.

[frickY]

PHP:

$eerstedag = mktime(0,0,0,date("n",time()),date("d",time()),date("Y",time()));
$vandaag = mktime(0,0,0,date("n",time()),date("d",time()),date("Y",time()));

Ikzelf had het liever zo gedaan;

PHP:

$eerstedag = $vandaag = mktime(0, 0, 0);

[ Voor 255% gewijzigd door frickY op 15-09-2005 16:13 ]

[Cavorka]

frickY schreef op donderdag 15 september 2005 @ 16:09:

PHP:

$eerstedag = mktime(0,0,0,date("n",time()),date("d",time()),date("Y",time()));
$vandaag = mktime(0,0,0,date("n",time()),date("d",time()),date("Y",time()));

Ikzelf had het liever zo gedaan;

PHP:

$eerstedag = $vandaag = mktime(0, 0, 0);

PHP:

$eerstedag = $vandaag = time() ;

[Michali]

Geeft maar weer eens aan hoe belangrijk het is om gewoon even in de manual te kijken of er niet een functie is die precies doet wat je nodig hebt.

[Soultaker]

Cavorka schreef op donderdag 15 september 2005 @ 16:56:

PHP:

$eerstedag = $vandaag = time() ;

En dat is dus níet hetzelfde.

Overigens heeft de code van frickY's collega ook het probleem dat time() meerdere malen aangeroepen wordt, maar de waarde kan variëren. Als je net pech hebt krijg je de dag van gisteren en de maand van vandaag en ligt $eerstedag een maand te ver vooruit.

[Woy]

Soultaker schreef op donderdag 15 september 2005 @ 19:46:
[...]

En dat is dus níet hetzelfde.

Overigens heeft de code van frickY's collega ook het probleem dat time() meerdere malen aangeroepen wordt, maar de waarde kan variëren. Als je net pech hebt krijg je de dag van gisteren en de maand van vandaag en ligt $eerstedag een maand te ver vooruit.

Dat zijn idd echt van die mooie foutjes die nooit voorkomen. Maar mocht het een keer gebeuren kom je er ook echt niet snel achter hoe het komt.

[frickY]

Cavorka schreef op donderdag 15 september 2005 @ 16:56:

PHP:

$eerstedag = $vandaag = time() ;

Dat zou je denken Alleen geeft de orginele functie de huidige datum met als tijdstip middennacht. Hoe jij het doet krijg je het exacte tijdstip.

Verder heeft Soultaker inderdaad ook een goed punt
Gelukkig werkt de desbetreffende collega hier niet meer.
Nu alleen mn baas nog zien te overtuigen dat het de investering van tijd waard is dergelijke onzin te corrigeren Maar ja.. "het werkt toch?"

[JeroenTheStig]

Niet alleen de programmeurs, maar ook compilers kunnen er soms een potje van maken. Dit kwam ik gisteren tegen in Oracle Forms 10g:


en

[NMe]

Oracle Forms is sowieso het meest brakke stukje software waar ik ooit mee gewerkt heb. Als je wat componenten op je form hebt staan en je resizet vervolgens je form, dan staat alles ineens anders.

[leuk_he]

OK, effe een kickje want wat ik gisteren tegen kwam:

Programmeur voegt weer functionaliteit toe aan een bepaald programma. Ik beschuldig hem ervan dat hij nu wel bloatware aan het maken is. En hij voegt vervolgens een BMI calculator toe als easter egg....

[Salandur]

leuk_he schreef op vrijdag 28 oktober 2005 @ 09:46:
OK, effe een kickje want wat ik gisteren tegen kwam:

Programmeur voegt weer functionaliteit toe aan een bepaald programma. Ik beschuldig hem ervan dat hij nu wel bloatware aan het maken is. En hij voegt vervolgens een BMI calculator toe als easter egg....

wat is daar slecht aan geprogrammeert dan?

Wat ik laatst tegen kwam:

Java:

  protected void initialize() throws ConfigurationException {
    config = getConfiguration();
    ExceptionFactory = ExceptionFactory.getInstance();
    sjabloonRepositoryFactory = SjabloonRepositoryFactory.getInstance(config);
    ServiceProviderFactory = ServiceProviderFactory.getInstance(config);
    stateManagerFactory = StateManagerFactory.getInstance();
  }

  protected Configuration getConfiguration() throws ConfigurationException {
    return Configuration.getDefault();
  }

met de volgende code in Configuration:

Java:

  public static Configuration getDefault() throws ConfigurationException {
    return new Configuration(PropertyNames.PROPERTIES_FILENAME);
  }

Een halve implementatie van het 'Singleton Pattern' dus. Nog leuker is dat de class van het eerste stukje bij elke aanroep van een servlet/soaplistener wordt geinstantieerd. En dus voor elke aanroep een Configuration object wordt aangemaakt. Efficient is wat anders lijkt me

[ Voor 56% gewijzigd door Salandur op 28-10-2005 10:49 . Reden: ff applicatie namen veranderd ]

[LuCarD]

Visual Basic:

Private Sub TXTSSNUMBER_DataChange()
On Error Resume Next
Dim X
For X = 1 To Len(TXTSSNUMBER.Text)
    If Asc(Mid(TXTSSNUMBER.Text, X, 1)) < 48 Or Asc(Mid(TXTSSNUMBER.Text, X, 1)) > 57 Then
        TXTSSNUMBER.Text = Replace(TXTSSNUMBER.Text, Mid(TXTSSNUMBER.Text, X, 1), "")
    End If
Next X
End Sub

Tja.....

[JeroenTheStig]

Bij het migreren van Oracle forms (4.5, 6.0, 6i) naar 10g maken we gebruik van een toolbox die gebruik maakt van de forms-API, geschreven in C. In deze toolbox is het mogelijk scripts te maken met het zogenaamde ScriptPascal. Nu ben ik bij java en .net gewend dat wanneer je buiten een array loopt te vorken je een outofbounds exception krijgt. Nu heb ik te weinig ervaring in talen als C en C++ om te zeggen dat dat hier ook zo is, maar in een scripttaal verwacht je toch minimaal dat het ook daar is afgeschermd om buiten je array te lopen klooien. Maar bij toeval kwam ik op het volgende:

Een forloop om elke karakter van een variabele van het type varchar2 op te halen:

code:

PROGRAM _progname_;

VAR
  v_number       : number;
  v_string       : varchar2;

BEGIN
  v_string := 'test';
  for v_number := 0 to length(v_string)-1 do
  begin
    logadd(v_string[v_number]);
  end;
END.

Resultaat:

code:

t
e
s

Hmm, waar is nou die 't' gebleven? Even de documentatie erbij gepakt. Wat blijkt nu: arrays worden met index 1 t/m de lengte van de array bij langs gelopen. Nog maar een keer:

code:

PROGRAM _progname_;

VAR
  v_number       : number;
  v_string       : varchar2;

BEGIN
  v_string := 'test';
  for v_number := 1 to length(v_string) do
  begin
    logadd(v_string[v_number]);
  end;
END.

Resultaat:

code:

t
e
s
t

Maar... ik had in het eerste script toch een index gebruikt die 'out of bounds' is? Toch maar even dit proberen:

code:

PROGRAM _progname_;

VAR
  v_number       : number;
  v_string       : varchar2;

BEGIN
  v_string := 'test';
  for v_number := 1 to 1000 do
  begin
    logadd(v_string[v_number]);
  end;
END.

Resultaat:

code:

t
e
s
t

c
e

x
d
‹

X
Ž
Œ

 



~
~
~
enzovoorts

Oftewel: Ik zit mijn geheugen te printen naar mijn outputscherm. Voor de gein nog maar even geprobeerd of ik mijn geheugen kan muteren:

code:

PROGRAM _progname_;

VAR
  v_number       : number;
  v_string       : varchar2;

BEGIN
  v_string := 'test';
  for v_number := 1 to 1000 do
  begin
    v_string[v_number] := 'a';
  end;
END.

Nou ja, zoals je al wel kunt raden loopt mijn toolbox snoeihard vast
Toch wel opmerkelijk dat je dit soort grappen uit kunt halen met bepaalde scripttaaltjes

[Paul]

Security-alert indienen bij Oracle / developer van die toolbox dat hun programma zo lek als een mandje is en je met de 3 simpelste regels code een buffer overflow exploit kunt maken (Goed, de code is simpel maar wat je nu buiten die buffer moet zetten om er daadwerkelijk een exploit van te maken is wat minder triviaal ).

[TeeDee]

C#:

        private bool CheckQueryString(string qstr)
        {
            bool _checkstring = false;
            _checkstring = true;
            return _checkstring;
        }

In de summary staat: ToDo: finish this function.
Leuk op een productie omgeving .

string qstr is de volledige querystring, welke (in a weird twisted state of mind) deze moet checken, waarschijnlijk op foutieve chars e.d.

[Voutloos]

Boktor schreef op vrijdag 09 december 2005 @ 09:23:
Nu heb ik te weinig ervaring in talen als C en C++ om te zeggen dat dat hier ook zo is, maar in een scripttaal verwacht je toch minimaal dat het ook daar is afgeschermd om buiten je array te lopen klooien.

C is ook niet echt dichtgetimmerd op dit gebied.

[NMe]

Voutloos schreef op vrijdag 09 december 2005 @ 22:56:
C is ook niet echt dichtgetimmerd op dit gebied.

Niet echt? Zeg maar gerust "helemaal niet".

[prototype]

En dat is de kracht van geheugenmanagement

[H!GHGuY]

Ach, zelfspot mag ook wel eens:

C#:

public class ExceptionUnwinder
{
   public static string Unwind(Exception e)
   {
       StringBuilder sb = new StringBuilder();
       while (e != null)
       {
           sb.Append("nog wat formatting meuk hier");
           sb.Append(e.ToString());
           sb.Append("nog wat formatting meuk hier");
           // vergeten: e = e.InnerException;
       }
       return sb.ToString();
   }
}

waarom gaat die foutafhandeling zo traag? tot je een OutOfMemoryException krijgt natuurlijk

Ja, ik had dit binnen de 5 seconden gevonden
Nee, als ik wakker ben schrijf ik dit soort onzin niet

Na dit stukje ben ik echter wel te spreken over de snelheid van .NET
Ik draaide dit op een machine met 1G RAM en het duurde slechts een paar seconden om dit vol te laten lopen... (weet echter niet hoeveel .NET hier ook effectief van consumeert... blijkbaar neemt Java genoegen met 512MB max of zo ?)

[ Voor 20% gewijzigd door H!GHGuY op 09-12-2005 23:55 ]

[Verwijderd]

Stukje code van een (vrouwelijke) collega, uit de eerste week dat ze bij ons kwam werken (na 3 jaar informaticaopleiding)

PHP:

$num = $_GET['nummer'];

switch($num) {
   case 1: $num = "01"; break;
   case 2: $num = "02"; break;
   case 3: $num = "03"; break;
   case 4: $num = "04"; break;
   case 5: $num = "05"; break;
   case 6: $num = "06"; break;
   case 7: $num = "07"; break;
   case 8: $num = "08"; break;
   case 9: $num = "09"; break;
}

Pure genious! (ze doet het nu wel al stukken beter)

[prototype]

Verwijderd schreef op zaterdag 10 december 2005 @ 16:32:
Stukje code van een (vrouwelijke) collega, uit de eerste week dat ze bij ons kwam werken (na 3 jaar informaticaopleiding)

PHP:

$num = $_GET['nummer'];

switch($num) {
   case 1: $num = "01"; break;
   case 2: $num = "02"; break;
   case 3: $num = "03"; break;
   case 4: $num = "04"; break;
   case 5: $num = "05"; break;
   case 6: $num = "06"; break;
   case 7: $num = "07"; break;
   case 8: $num = "08"; break;
   case 9: $num = "09"; break;
}

Pure genious! (ze doet het nu wel al stukken beter)

, wat voor informatica opleiding deed ze dan?
De valkuil zit hem eigenlijk in het feit dat je goed types moet onderscheiden, zo triviaal blijkt het nog niet eens te zijn :):

PHP:

$num = $_GET['nummer'];

//wat is $num nou precies, i.e. een string, int of double?
//Daar moet je eerst even op testen, mbv is_string/is_int/is_float etc.. en dan gepaste maatregelen treffen.

if ($num > 0 && $num < 10)
{
    $num = '0' . (string)((int) $num);
}

[Aapje]

* Aapje kijkt naar boven
* Aapje denkt zoiets heb ik ook gemaakt
't Werkt
Maar ziet er niet uit

Visual Basic:

    Public Function repeatstr(ByVal strStr As String, ByVal strNum As Short)
        'Ik had een functie nodig die in vb clasic: str() was
        'Kon hem niet vinden dus zelf maar 1 gemaakt :-)
        'strStr = "t"
        'strNum = 4
        'Output: tttt
        'Otherwords: one 1337 function ;-)
        Dim repeatstrI As Short
        repeatstr = ""
        For repeatstrI = 1 To strNum
            repeatstr &= strStr
        Next repeatstrI
    End Function

    Public Function nulzeer(ByVal strNummer As String, ByVal strNullen As Short)
        'Nulzeer stukkie :P
        'strNummer = 7
        'strNullen = 2
        'Output: 007
        'Otherwords: 1337 function :-)
        nulzeer = repeatstr("0", (strNullen - Len(strNummer.ToString))) & strNummer
    End Function

vb.net ;p

Weet iemand toevallig de 'str()' functie uit asp wat dat is in vb.net Heb er uren naar gezocht..
Ben er vrijwel zeker van overtuigt dat ie er is maar kan um niet vinden
Vandaar deze prut oplossing

[Michali]

@prototype: Zou dit niet beter zijn?:

PHP:

$num = sprintf('%02d', $num);

[ Voor 16% gewijzigd door Michali op 10-12-2005 17:41 ]

[prototype]

Michali schreef op zaterdag 10 december 2005 @ 17:41:
@prototype: Zou dit niet beter zijn?:

PHP:

$num = sprintf('%02d', $num);

Als vervanging voor die concat: over smaak valt niet te twisten Ik denk dat het qua performance weinig uit zal maken in dit geval

[ Voor 10% gewijzigd door prototype op 10-12-2005 18:24 ]

[MTWZZ]

BaBoOn schreef op zaterdag 10 december 2005 @ 17:38:
Weet iemand toevallig de 'str()' functie uit asp wat dat is in vb.net Heb er uren naar gezocht..
Ben er vrijwel zeker van overtuigt dat ie er is maar kan um niet vinden
Vandaar deze prut oplossing

String.PadLeft(Int32,Char) of String.PadRight(Int32,Char)
als in:

Visual Basic:

Dim str As String
str = "BEAF"

str = str.PadLeft(4,'0')
Console.WriteLine(str)
' output: 0000BEAF

[Aapje]

MTWZZ schreef op zaterdag 10 december 2005 @ 19:23:
[...]


String.PadLeft(Int32,Char) of String.PadRight(Int32,Char)
als in:

Dank u zeer Scheelt ook weer in performance van me script

[Michali]

Het is al eens gezegd hier, maar ik wil hem toch even hier in zetten. Ik bedoel, hiervan ga je toch gewoon huilen

PHP:

<?php

class Test
{
    public function __toString()
    {
        return "bar";
    }
}

$test = new Test();
print "foo ";
print $test;
print "\n";
print "foo " . $test . "\n";

?>

output:

foo bar
foo Object id #1

Met afstand, php's meest domme feature (of is er stiekem eentje toch nog slechter?). Ik vind php een fijn taaltje, maar dit is echt te dom voor woorden.

[Verwijderd]

[edit] knip moet beter lezen

toch even iets:

code:

print "foo" . $test . "bar";

^^ valt volgens mij ook onder het hoofdstuk 'smerige code'

code:

printf("foo %s bar", $test)

Is dan netter. Nu weet ik alleen niet of dat dezelfde problemen zou opleveren

[ Voor 179% gewijzigd door Verwijderd op 22-12-2005 16:58 ]

[Grijze Vos]

Verwijderd schreef op zaterdag 10 december 2005 @ 16:32:
Stukje code van een (vrouwelijke) collega, uit de eerste week dat ze bij ons kwam werken (na 3 jaar informaticaopleiding)

PHP:

$num = $_GET['nummer'];

switch($num) {
   case 1: $num = "01"; break;
   case 2: $num = "02"; break;
}

Pure genious! (ze doet het nu wel al stukken beter)

Hehe, ik heb laatst zelf een veld in MySQL padding gegeven omdat ik geen zin had om die data in php nog te formatten. Ook best fout eigenlijk.

[ Voor 4% gewijzigd door Grijze Vos op 22-12-2005 17:00 ]

[Michali]

Verwijderd schreef op donderdag 22 december 2005 @ 16:56:
[edit] knip moet beter lezen

toch even iets:

code:

print "foo" . $test . "bar";

^^ valt volgens mij ook onder het hoofdstuk 'smerige code'

code:

printf("foo %s bar", $test)

Is dan netter. Nu weet ik alleen niet of dat dezelfde problemen zou opleveren

PHP:

printf("foo %s", $test);

Output:

foo Object id #1

Dat valt bij mij ook onder smerige code. Imo is het beter om dan dit te doen:

PHP:

?>
foo <?=$test?>
<?

Maar daar gaat het nu even niet om

[GlowMouse]

Ongeveer 4 jaar geleden begon ik met PHP, en wou ik gelijk een site maken SQL had ik een paar voorbeeldjes van gezien, en PHP lukte wel. Krijg je zulke constructies:

PHP:

$query="UPDATE table SET row1='$1' WHERE id='$id";
mysql_query($query);
$query="UPDATE table SET row2='$2' WHERE id='$id";
mysql_query($query);
$query="UPDATE table SET row3='$3' WHERE id='$id";
mysql_query($query);
$query="UPDATE table SET row4='$4' WHERE id='$id";
mysql_query($query);

Queries gingen dus niet zo goed, maar het kon nog erger:

PHP:

$query="SELECT * FROM pages";
$result=mysql_query($query);
$num=mysql_numrows($result);
$i=0;
while ($i < $num) {
$id=mysql_result($result,$i,"id");
if($id==$pageid) {
$title=mysql_result($result,$i,"title");
$content=mysql_result($result,$i,"content");
echo "[prachtige pagina]";
}
$i++;
}

Achteraf gezien mag ik van geluk spreken dat de server zo snel, en het aantal pagina's zo klein was

_{Disclaimer: variabelen zijn wat hernoemd en her en der is de code wat ingekort, maar het idee is onveranderd}

[We Are Borg]

Zelfspot is heerlijk

JavaScript:

unction Start(page) {

OpenWin = this.open(page, "CtrlWindow", "toolbar=NO,menubar=NO,location=NO,scrollbars=no,resizable=no,width=500,height=600");

}

function Start1(page) {

OpenWin = this.open(page, "CtrlWindow", "toolbar=NO,menubar=NO,location=NO,scrollbars=no,resizable=no,width=400,height=150");

}

function Start2(page) {

OpenWin = this.open(page, "CtrlWindow", "toolbar=NO,menubar=NO,location=NO,scrollbars=no,resizable=no,width=250,height=50");

}

function Start3(page) {

OpenWin = this.open(page, "CtrlWindow", "toolbar=NO,menubar=NO,location=NO,scrollbars=no,resizable=no,width=700,height=750");

}

function Start4(page) {

OpenWin = this.open(page, "CtrlWindow", "toolbar=NO,menubar=NO,location=NO,scrollbars=no,resizable=no,width=500,height=100");

}

Werkt super....dat wel

[ Voor 8% gewijzigd door We Are Borg op 22-12-2005 18:05 ]

[Olaf van der Spek]

Macros schreef op zaterdag 10 december 2005 @ 21:39:
Java springt niet zo efficient met het geheugen om, dus het is handig dat je dat soort dingen kan bepalen. Bij C programma's is het veel lastiger om dit te doen, die kan dus door een geheugen lek je hele ram vol laten lopen.

Het is de taak van het besturingssysteem dit soort limieten in te stellen en bij te houden, niet van een taal.

[zeroxcool]

OlafvdSpek schreef op donderdag 22 december 2005 @ 18:06:
[...]

Het is de taak van het besturingssysteem dit soort limieten in te stellen en bij te houden, niet van een taal.

En aan de programmeur ze goed te gebruiken .

[crisp]

We Are Borg schreef op donderdag 22 december 2005 @ 18:04:
Zelfspot is heerlijk
[...]

Ik zie zo nog 2 WTF's:
1) OpenWin wordt nergens gedeclareerd en zal in deze constructie een warning genereren en global gemaakt worden. De vraag is of dat ook noodzakelijk is; doe je er ueberhaupt iets mee?
2) het gebruik van het this keyword vind ik hier erg vreemd. open() is een method van het window object, maar wie zegt dat de executie van deze functies ook altijd in die scope plaatsvind? Of prototype je deze functies als method van een ander soort object dat ook een open() method heeft?

[Michali]

@We Are Borg: mooi stukje code, er is zelfs fuzzy logic gebruikt. Voor de lezer dan: scrollbars? no. resizalbe? no. toolbar, menubar, location? NO!

[Delphi32]

Delphi:

procedure TMainForm.UpdateFooButton;
var
  useAdvancedMode : boolean;
begin
  useAdvancedMode := UserHasRightsForAdvancedMode and LicenseIsPaid;
  
  FooButton.Enabled := useAdvancedMode or not useAdvancedMode;
end;

Typisch voorbeeld van gewijzigde specs, progger die hard z'n best doet om die wijzigingen door te voeren en vergeet te kijken naar the bigger picture. Ik vond ergens dat er wel een filosofische gedachte zat in de volstrekt overbodig geworden assignment, dus ik heb het (in commentaar) laten staan voor het nageslacht.

[bodiam]

Delphi32 schreef op vrijdag 23 december 2005 @ 00:02:

Delphi:

procedure TMainForm.UpdateFooButton;
var
  useAdvancedMode : boolean;
begin
  useAdvancedMode := UserHasRightsForAdvancedMode and LicenseIsPaid;
  
  FooButton.Enabled := useAdvancedMode or not useAdvancedMode;
end;

Typisch voorbeeld van gewijzigde specs, progger die hard z'n best doet om die wijzigingen door te voeren en vergeet te kijken naar the bigger picture. Ik vond ergens dat er wel een filosofische gedachte zat in de volstrekt overbodig geworden assignment, dus ik heb het (in commentaar) laten staan voor het nageslacht.

Overigens wel geweldige variabelenamen. Ik zie ze meestal als:

Delphi:

procedure TMainForm.UpdateFooButton;
var
  tb : boolean;
begin
  tb := hasr and licip;
  
  FooButton.Enabled := tb or not tb;
end;

_{okee, I know, die tb was flauw....maar het ging om de essentie.}

[edit]
Overigens ook wel een mooie:

Java:

i = list.getSize();
while( i > 0 )
{
   i = i --;
   try
   {
     list.remove(i);
     list2.remove(i);
   }
   catch( Exception e)
   {
     break;
   }
}

Wow....hoeveel fouten je hierin kunt hebben, brilliant!

[ Voor 17% gewijzigd door bodiam op 23-12-2005 00:22 ]

[Expecho]

[b][message=24865366,noline]bodiam schreef op vrijdag 23 december 2005 @
...

Overigens ook wel een mooie:

Java:

i = list.getSize();
while( i > 0 )
{
   i = i --;
   try
   {
     list.remove(i);
     list2.remove(i);
   }
   catch( Exception e)
   {
     break;
   }
}

Wow....hoeveel fouten je hierin kunt hebben, brilliant!

Euhm, sowieso gaat het mis als list2 minder items bevat dan list.

[Jaap-Jan]

Expecho schreef op vrijdag 23 december 2005 @ 09:40:
[...]


Euhm, sowieso gaat het mis als list2 minder items bevat dan list.

En nog wel meer
i-- doet hetzelfde als i =- 1 en dat is in principe weer gelijk aan i = i - 1.

Máár, als je een toekenning doet van i-- aan een variabele, dan krijgt die variabele de óude waarde van i. Dit heet postdecrement. Dus als je

Java:

i = i--;

doet, dan verandert i nooit, dus je hebt een oneindige lus gebouwd . Dit omdat er bij gebruik van postdecrement en postincrement een tijdelijke 'i' wordt bewaard. Daarna wordt 'i' verlaagd en in zichzelf opgeslagen en daarna heb je je assignment en wordt de oude waarde van 'i' opgeslagen in 'i'.

Deze code zou goed zijn gegaan als er

Java:

i = --i;

zou zijn gedaan, want dan wordt i eerst verlaagd en dan toegekend aan i (predecrement).

Maar ik ga er even vanuit dat hij 2 lijsten (type List) in zijn geheel wil leeggooien, dan kun je ook gewoon

Java:

list.clear();
list2.clear();

doen

[ Voor 38% gewijzigd door Jaap-Jan op 23-12-2005 12:47 ]

[bodiam]

Japie_17 schreef op vrijdag 23 december 2005 @ 12:00:
[...]
Maar ik ga er even vanuit dat hij 2 lijsten (type List) in zijn geheel wil leeggooien, dan kun je ook gewoon

Java:

list.clear();
list2.clear();

doen

Daar heb ik het ook mee vervangen. Maar de persoon in kwestie wist niet dat de methode 'clear' bestond, en dit leek hem makkelijker . Behalve dat de code niet werkt (maar dat kan ook mijn fout zijn ), is het gevaar dat als de lijsten niet even lang zijn, ze niet beiden gewist worden. Een erg fijne bug om op te lossen!

[We Are Borg]

Michali schreef op donderdag 22 december 2005 @ 23:30:
@We Are Borg: mooi stukje code, er is zelfs fuzzy logic gebruikt. Voor de lezer dan: scrollbars? no. resizalbe? no. toolbar, menubar, location? NO!

Idd, net een vragenlijstje

@crisp: I know, ranzig en het zou binnen 5 min gefixed kunnen zijn maar ja...ben lui

[Jaap-Jan]

bodiam schreef op vrijdag 23 december 2005 @ 13:03:
[...]


Daar heb ik het ook mee vervangen. Maar de persoon in kwestie wist niet dat de methode 'clear' bestond, en dit leek hem makkelijker . Behalve dat de code niet werkt (maar dat kan ook mijn fout zijn ), is het gevaar dat als de lijsten niet even lang zijn, ze niet beiden gewist worden. Een erg fijne bug om op te lossen!

Het kan ook niet werken, probeer maar eens uit:

Java:

int i = 5;
System.out.println("i = " +i);
i = i--;
System.out.println("i = " +i);

De output is dan:

code:

i = 5
i = 5

Et voilà, je eindeloze lus .

[ Voor 4% gewijzigd door Jaap-Jan op 23-12-2005 15:14 ]

[MTWZZ]

OlafvdSpek schreef op donderdag 22 december 2005 @ 18:06:
Het is de taak van het besturingssysteem dit soort limieten in te stellen en bij te houden, niet van een taal.

Voor wat dat java programma van de wereld ziet is de JRE het besturingssysteem en niet het systeem waar de JRE op draait.
Ok een java programma ziet wel meer maar het feit waarom de JRE dit doet is op zich best logisch.

[Woy]

MTWZZ schreef op vrijdag 23 december 2005 @ 15:16:
[...]

Voor wat dat java programma van de wereld ziet is de JRE het besturingssysteem en niet het systeem waar de JRE op draait.
Ok een java programma ziet wel meer maar het feit waarom de JRE dit doet is op zich best logisch.

Ok maar de JRE zou zich wel aan moeten passen aan het systeem waar het op draait. Die kan natuurlijk wel meer 'zien'.

[MTWZZ]

rwb schreef op vrijdag 23 december 2005 @ 17:13:Ok maar de JRE zou zich wel aan moeten passen aan het systeem waar het op draait. Die kan natuurlijk wel meer 'zien'.

True, ik ben zelf ook vaak zat tegen die limiet aangelopen en ik vind het nog steeds erg vervelend dat je het ook niet on-the-fly aan kan passen (ook logisch eigenlijk )

[Woy]

Net kom ik weer hele handige exception handling tegen van een oud collega

C#:

try{
    ....
}
catch( Exception e ){
    throw e;
}

Ja zo heb je lekker veel aan je try/catch blok

[Janoz]

Als er nog een finaly blok achter gezeten had, dan zou dat stukje code nog wel verdedigbaar kunnen zijn,

[Woy]

Janoz schreef op woensdag 04 januari 2006 @ 10:20:
Als er nog een finaly blok achter gezeten had, dan zou dat stukje code nog wel verdedigbaar kunnen zijn,

Ja dan wel op wat opruiming te doen ja. Maar dat is dan vooral afhankelijk van wat je in je try blok doet. Als je daar wat aan het doen bent waar je een exception niet kunt handlen maar wel opruim werk moet doen. Maar dan zou ik denk toch meestal mijn exception in een nieuwe exception wrappen zodat je eventueel nog wat extra informatie mee door kunt geven.

[Feyd-Rautha]

rwb schreef op woensdag 04 januari 2006 @ 10:17:
Net kom ik weer hele handige exception handling tegen van een oud collega

C#:

try{
    ....
}
catch( Exception e ){
    throw e;
}

Ja zo heb je lekker veel aan je try/catch blok

Aanschouw:

Java:

public void methodX() throws Exception {
  ...
}

Dat is toch semantisch hetzelfde als:

code:

public void methodX() {
 try {
   ...
 }
 catch(Exception ex) {
  throw ex;
 }
}

Het komt er hier toch gewoon op neer om uw exception verder 'door te sturen'. Dit lijkt me dus niet direct een echt slecht programmeer-voorbeeld. Ik weet wel niet of C# een 'throws'-statement heeft (zoals in Java)

[whoami]

Nu ben ik gaan Java held, maar wil throws Exception in Java niet zeggen dat , als je die method aanroept, deze in een try/catch block moet staan, die ervoor zorgt dat de exception die het throws statement definieert, opvangt ?
_{wat een zin ?}

Waarom is dat dan semantisch hetzelfde als dat C#code voorbeeld ? Dat code voorbeeld gaat toch gewoon de exceptie doorgooien op de stack.
Echter, dit:

code:

try
{
   Bliep();
}
catch( Exception ex )
{
   throw ex;
}

is semantisch hetzelfde als:

code:

Bliep();

Hier ga je nl. geen exceptie opvangen, dus, deze wordt al automatisch doorgegooid.

_{C# kent geen throws statement}

[ Voor 4% gewijzigd door whoami op 04-01-2006 12:29 ]

[momania]

Feyd-Rautha schreef op woensdag 04 januari 2006 @ 12:22:
[...]


Dat is toch semantisch hetzelfde als:

code:

public void methodX() {
 try {
   ...
 }
 catch(Exception ex) {
  throw ex;
 }
}

Neen,

Exception is een checked exception, dus zou de method signature ook hier met 'throws Exception moeten zijn:

Java:

public void methodX() throws Exception {
 try {
   ...
 }
 catch(Exception ex) {
  throw ex;
 }
}

Dan is het catchen alleen en weer doorgooien dus totaal zinloos zonder finally block.

[Woy]

idd, in java ben je verplicht om aan te geven welke exceptions je methode kan opleveren ( Met uitzondering van RuntimeExceptions ) en een aanroepende methode is dan ook verplicht om zichzelf tegen deze exception te beveiligen danwel aan te geven dat deze exception ook door die method gegooid kan worden.

In C# kan je niet aangeven welke exceptions je allemaal kan gooien en je bent ook niet verplicht ( Vanuit de taal dan ) om exceptions op te vangen. Dus het stukje code wat ik poste was precies hetzelfde geweest als je alleen de code wat op de puntjes staat had geplaatst aangezien een exception automatisch al doorgegooid wordt als hij niet opgevangen wordt.
dus

C#:

public void Method(){
    ...
}
//is hetzelfde als
public void Method(){
    try{
        ...
    }
    catch( Exception ex ){
        throw ex;
    }
}

[ Voor 13% gewijzigd door Woy op 04-01-2006 15:09 ]

[Erkens]

Je kan het wel op die manier doen als tijdelijke oplossing, zodat je later als je de exception handling gaat schrijven niet meer die try/catch blokken hoeft te inserten op de juiste plekken. Hoewel je er dan een 'todo' comment bij zet

[Woy]

Erkens schreef op woensdag 04 januari 2006 @ 15:17:
Je kan het wel op die manier doen als tijdelijke oplossing, zodat je later als je de exception handling gaat schrijven niet meer die try/catch blokken hoeft te inserten op de juiste plekken. Hoewel je er dan een 'todo' comment bij zet

Ja idd, en het hoort natuurlijk ook niet echt thuis in een product wat al in productie is genomen

[Erkens]

rwb schreef op woensdag 04 januari 2006 @ 16:30:
[...]

Ja idd, en het hoort natuurlijk ook niet echt thuis in een product wat al in productie is genomen

nee ok, dan niet, hoewel het geen ramp is natuurlijk, het doet nog steeds wat je zou verwachten

[Vedett.]

whoami schreef op woensdag 04 januari 2006 @ 12:28:
Waarom is dat dan semantisch hetzelfde als dat C#code voorbeeld ? Dat code voorbeeld gaat toch gewoon de exceptie doorgooien op de stack.
Echter, dit:

code:

try
{
   Bliep();
}
catch( Exception ex )
{
   throw ex;
}

is semantisch hetzelfde als:

code:

Bliep();

Hier ga je nl. geen exceptie opvangen, dus, deze wordt al automatisch doorgegooid.

_{C# kent geen throws statement}

Dacht eigenlijk dat dit wel invloed had op de stack. Stacktrace gaat dan tot deze functie. Heb je enkel throw; dan loopt de stacktrace door tot de oorspronkelijke sectie. De reden waarom ik altijd allen terug throw; doe.

?We zijn toch over C# bezig?? in Java weet ik het nie!?

edit:

In java heeft het blijkbaar geen effect. Over het .Net gedrag ben ik blijkbaar wel correct. (wordt mijn dag weer goed van )

Meer info:
http://www.tkachenko.com/blog/archives/000352.html

[ Voor 13% gewijzigd door Vedett. op 04-01-2006 19:10 ]

[Verwijderd]

Janoz schreef op woensdag 04 januari 2006 @ 10:20:
Als er nog een finaly blok achter gezeten had, dan zou dat stukje code nog wel verdedigbaar kunnen zijn,

Nu ben ik niet zo goed thuis in C#, maar in Java is de catch niet nodig als je een try wilt doen:

Java:

try{
    ....
}
finally {
    ....
}

Is perfect valide code. Doet een beetje denken aan stack-guards in C++.

[Woy]

Verwijderd schreef op woensdag 04 januari 2006 @ 21:10:
[...]


Nu ben ik niet zo goed thuis in C#, maar in Java is de catch niet nodig als je een try wilt doen:

Java:

try{
    ....
}
finally {
    ....
}

Is perfect valide code. Doet een beetje denken aan stack-guards in C++.

Ja dat mag in C# ook gewoon ja.

[Janoz]

Vandaar ook mijn "verdedigbaar kunnen zijn". Dat is wat anders dan "goed".

[Michali]

Klopt het dat die try .. finally combi op die manier eigenlijk een soort duidelijkere (en nettere) vervanging is van zoiets:

Java:

try {
  .....
}
catch ( Exception e ) { }
....

En wordt een finally nou eerder uitgevoerd dan een catch?

[pjvandesande]

Een finally word als laatste uitgevoerd, na de catch. Als je een Exception eat-up wilt doen kun je een lege catch gebruken.

Maar een Exception eat-up is ook aardig !done. Er zijn situaties waar ik het wel is gebruikt heb.

[ Voor 7% gewijzigd door pjvandesande op 05-01-2006 10:43 ]

[Janoz]

Finaly wordt ALTIJD uitgevoerd. Ook als er geen exception optreed. Finaly eet de exception NIET op. Een voorbeeld voor het gebruik van finaly is:

code:

try {
  open een verbinding
  doe dingetjes waarbij ook een exception op kan treden
} finaly {
  probeer de verbinding te sluiten
}

Dit stukje code handelt lokaal niet de exception af, dat wordt opvergelaten aan de aanroeper, maar ruimt nog wel zijn eigen rommel op.

[ Voor 19% gewijzigd door Janoz op 05-01-2006 10:34 ]

[Michali]

En als de exception dan weer gegooid wordt, in de catch dus, voordat de finally is uitgevoerd. Wordt dan eerst gewacht totdat de exception ergens is gestrand voordat de finally(s) uitgevoerd worden?

[Janoz]

(Ik praat over java) De finaly wordt uitgevoerd na de body van de try of na de catch, maar voor de executie van de aanroeper. Ook wanneer je in je try blok een return hebt staan wordt eerst de finaly uitgevoerd voordat de aanroeper verder gaat.

[Erkens]

Dit stukje code is geschreven het afgelopen jaar. Wat het doet is de dagen van de week outputten voor een calendar.
Het werkte prima aldus die gast en dus niemand keek er naar om, hij was toen een van de weinige die aan deze applicatie werkte en het was allemaal getest enzo. (inmiddels werkt die hier niet meer)
Totdat het 2006 werd en de weken niet meer met maandag begonnen maar met dinsdag

PHP:

<tr>
  <td class="calendar_dayname"><?=strftime("%a", mktime(0, 0, 0, 0, -1))?></td> 
  <td class="calendar_dayname"><?=strftime("%a", mktime(0, 0, 0, 0, 0))?></td>
  <td class="calendar_dayname"><?=strftime("%a", mktime(0, 0, 0, 0, 1))?></td> 
  <td class="calendar_dayname"><?=strftime("%a", mktime(0, 0, 0, 0, 2))?></td> 
  <td class="calendar_dayname"><?=strftime("%a", mktime(0, 0, 0, 0, 3))?></td> 
  <td class="calendar_dayname"><?=strftime("%a", mktime(0, 0, 0, 0, 4))?></td> 
  <td class="calendar_dayname"><?=strftime("%a", mktime(0, 0, 0, 0, 5))?></td> 
</tr>

[Robtimus]

Vedett. schreef op woensdag 04 januari 2006 @ 19:05:
Dacht eigenlijk dat dit wel invloed had op de stack. Stacktrace gaat dan tot deze functie. Heb je enkel throw; dan loopt de stacktrace door tot de oorspronkelijke sectie. De reden waarom ik altijd allen terug throw; doe.

Veel Exception subclasses hebben een constructor waarin je een Throwable (dus ook Exception) als cause kunt opgeven. In de stacktrace krijg je dan eerst je nieuwe Exception gevolgd door "caused by" en je oude Exception. Die doet dat dan ook weer totdat er geen cause is.

Helaas ondersteunt niet elke Exception subclass dit.

[Janoz]

Bij java wordt de stacktrace in de exception geplaatst bij het aanmaken van de exception. Wanneer je dezelfde exception weer opnieuw throwed wordt de stacktrace dus niet gewist. Bij .Net wordt de stacktrace blijkbaar door het throw commando gevuld (wat ik toch wat tegenstrijdig vind. Zal wel passen bij de 'we willen niks van onze internals laten zien' strategie van MS)

[pjvandesande]

Janoz schreef op donderdag 05 januari 2006 @ 14:09:
Bij java wordt de stacktrace in de exception geplaatst bij het aanmaken van de exception. Wanneer je dezelfde exception weer opnieuw throwed wordt de stacktrace dus niet gewist. Bij .Net wordt de stacktrace blijkbaar door het throw commando gevuld (wat ik toch wat tegenstrijdig vind. Zal wel passen bij de 'we willen niks van onze internals laten zien' strategie van MS)

Je hebt de mogelijkheid om een geheel nieuwe exception te werpen waarbij de oude exception verloren gaat, dus ook de stack-trace.
Hier kies je zelf voor alleen een meer gebruikelijke methode is om de exception te verpakken. Dus je eigen exception te gooien maar de exception die jij hebt opgevangen in je eigen exception stoppen als InnerException.

[kenneth]

Janoz schreef op donderdag 05 januari 2006 @ 14:09:
Bij .Net wordt de stacktrace blijkbaar door het throw commando gevuld (wat ik toch wat tegenstrijdig vind. Zal wel passen bij de 'we willen niks van onze internals laten zien' strategie van MS)

Oh? Als SSMS ( = .NET 2.0) op z'n bek gaat krijg een stacktrace die teruggaat tot Grace Hopper

[Janoz]

@questa: Ja dat snap ik. Maar als je dezelfde exception opnieuw gooit wordt (naar wat ik uit eerdere posts hier op kan maken) blijkbaar de stacktrace ook verwijderd.

Vergelijk:

code:

try {
  blaat
} catch( Exception e) {
  throw e;
}

met

code:

try {
  blaat
} catch( Exception e) {
  throw new Exception(e.getMessage());
}

Volgens wat ik hier lees zijn deze twee stukjes code in .NET equivalent (als in leveren dezelfde message en dezelfde stacktrace op).

[pjvandesande]

Dit klopt. Wil je je stacktrace behouden dan moet je of je inner exception setten of geen specific type afvangen maar gewoon:

C#:

catch
{
     // Behoud de stacktrace.
     throw;
}

[Koppensneller]

Dit kwam ik laatst tegen in de code van een klasgenoot waarmee ik samen aan een project werkte. Je moet dan even weten dat ZonneZeiler en IonenStraler subklassen zijn van RuimteSchip.

Java:

public class RuimteSchip
{
   //constructor, attributes en andere rotzooi...

   public void Schiet()
   {
      if(this instanceof ZonneZeiler)
      {
          //doe iets
      }
      else if(this instanceof IonenStraler)
      {
          //doet iets anders
      }

   }
}

Ik heb hem toen toch maar eens even verteld waarom we eigenlijk inheritence gebruiken

[ Voor 5% gewijzigd door Koppensneller op 05-01-2006 17:07 ]

[Verwijderd]

Hallo
Ik heb nu een groot deel van het topic gelezen, en wil toch ook eens iets toevoegen:

Wij moesten ooit eens voor school een webapplicatie maken in php. (ik volg industrieel ingenieur electronica). We hebben ook 2 studieduurverkorters in onze klas, die automechanica hadden gevolgd. Die hadden nog nooit geprogrammeerd, on nooit zelfs maar HTML gezien. Dus zij beginnen aan die applicatie, en het kwam niet goed, ze bleven maar errors krijgen.

Tijdens hun voorstelling vertelden ze dus dat ze die problemen hadden, en dat ze iets goed gevonden hadden. Ze voegden 1 regel toe aan hun script, en alles was opgelost. Dit was de regel:

code:

<?php
       error_reporting(0);
?>

Echt een fantastische oplossing Het werkte natuurlijk niet, maar de errors waren toch al weg

En een ander fantastische oplossing kwam van mezelve:
In mijn aller aller eerste php projectje heb ik ooit eens een hele webpagina ge-echo'd. Dit kwam omdat het toen voor mij leek alsof je een 'if' in php niet mocht stoppen met ?> Je kreeg dus dit:

PHP:

<?php
     if(something)
    {
     echo '<html>';
     echo '<head>'
     .....
     }
?>

Redelijk stom dus, maar kom, de docente had dat niet eens door... Wie is dan de stomste?

En mijn aller eerste grotere programma ooit (nogin Qbasic, 13 ofzo) was een text based adventure. De code was echt zielig: een lange aaneenschakeling van goto's, werd dus heel ingewikkeld, zodat je soms niet meer wist wat nu gerund werd. En dat ik dan nog kwaad was op iemand die zei dat ik geordend moest proggen

[ Voor 44% gewijzigd door Verwijderd op 05-01-2006 18:28 ]

[GF]

questa schreef op donderdag 05 januari 2006 @ 16:57:
Dit klopt. Wil je je stacktrace behouden dan moet je of je inner exception setten of geen specific type afvangen maar gewoon:

C#:

catch
{
     // Behoud de stacktrace.
     throw;
}

Ook nuttig zo'n stuk code. Enige wat je hier uit kan afleiden is dat er een exceptie kan optreden. Welke? Vang alle mogelijke excepties apart op en maak geen gebruik van algemene exception classes. Dat vind ik toch zo ranzig

Voorbeeldje zoals het wel moet:

C#:

try
{
  string blaat = "0030";
  int example = Convert.ToInt32(blaat);
}
catch(FormatException)
{
  throw;
}
catch(OverflowException)
{
  throw;
}

of

C#:

try
{
  string blaat = "0030";
  int example = Convert.ToInt32(blaat);
}
catch(FormatException ex)
{
  // do something with the exception like a dialog or something
}
catch(OverflowException ex)
{
  // do something with the exception like a dialog or something
}

Dit is ook typisch een voorbeeld van ranzigheid die ik erg vaak zie (vooral bij afgestudeerden van HIO Arnhem (wordt dat daar zo aangeleerd oid?)).

C#:

public bool DoSomething()
{
  try
  {
    string blaat = "0030";
    int example = Convert.ToInt32(blaat);

    return true;
  }
  catch(Exception ex)
  {
    return false;
  }
}

En dit gaat dan de hele applicatie door.

Nog een voorbeeld

C#:

foreach (Item item in items)
{
  if(condition1 && condition2 && condition3)
  {
    if(condition4 && condition5 && condition6)
    {
      if(condition7 && condition8 && condition9)
      {
        // do your thing
      }
    }
  }
}

Doe dit aub zo (oid.). Lees een stuk prettiger (ook voor jezelf)

C#:

foreach (Item item in items)
{
  if(!condition1 || !condition2 || !condition3)
  {
    continue;
  }
  
  if(!condition4 || !condition5 || !condition6)
  {
    continue;
  }

  if(!condition7 || !condition8 || !condition9)
  {
    continue;
  }

  // do your thing
}

[ Voor 56% gewijzigd door GF op 05-01-2006 20:38 . Reden: && omgetoverd naar || ]

[Mithrandir]

Nog een voorbeeld

C#:

foreach (Item item in items)
{
  if(condition1 && condition2 && condition3)
  {
    if(condition4 && condition5 && condition6)
    {
      if(condition7 && condition8 && condition9)
      {
        // do your thing
      }
    }
  }
}

Doe dit aub zo (oid.). Lees een stuk prettiger (ook voor jezelf)

C#:

foreach (Item item in items)
{
  if(!condition1 && !condition2 && !condition3)
  {
    continue;
  }
  
  if(!condition4 && !condition5 && !condition6)
  {
    continue;
  }

  if(!condition7 && !condition8 && !condition9)
  {
    continue;
  }

  // do your thing
}

Het is niet zo dat ik jouw code erg veel mooier vind... Het hoort gewoon in 1 if-statement, met bijvoorbeeld 3 conditions op een regel. Veel leesbaarder...

C#:

foreach (Item item in items)
{
  if(condition1 && condition2 && condition3 &&
    condition4 && condition5 && condition6 &&
    condition7 && condition8 && condition9)
    {
  // do your thing
  }
}

Overigens horen je &&-en OR's te zijn

[ Voor 26% gewijzigd door Mithrandir op 05-01-2006 19:40 ]

[Paul]

GF schreef op donderdag 05 januari 2006 @ 18:33:
Nog een voorbeeld

C#:

// geneste if-jes

Doe dit aub zo (oid.). Lees een stuk prettiger (ook voor jezelf)

C#:

// losse ifjes met loop-control

Ik zou het eigenlijk eerder zo doen:

C#:

foreach (Item item in items)
{
  if (condition1 &&
      condition2 && 
      condition3 &&
      condition4 &&
      condition5 &&
      condition6 &&
      condition7 &&
      condition8 &&
      condition9 )
  {
      // do your thing
  }
}

eventueel nog met de AND-operator aan het begin van de regel eronder, beetje afhankelijk hoe lang de condities zijn / hoeveel ze in lengte verschillen.

Zijn het erg korte condities of is er een repeterend patroon wil ik er nog wel een paar per regel zetten maar vanaf 3 condities (ongeveer, voor a && b && c && d && e neem ik de moeite niet, voor CalculteSomething(x, y, z) && DoSomeBlackVoodoo(a, b, c) && that->blaat->nogIets->IsIt?(foo->Bar()) al eerder) zet ik iedere conditie op zijn eigen regel.

[GF]

Het was een layout opzet. Geen goed code gebruikt (heb and's -> or's gemaakt).

En het aantal conditions is hier 3 om het leesbaarder te houden qua voorbeeld. Wat als het er al 6 zijn bij de eerste if? en dit dan bijv 3 keer. Ga je dan 9 conditions in 1 if gooien? Of als er nog gewone code regels tussen de ifjes moeten?

Voorbeeld:

C#:

foreach (Item item in items)
{
  if(!condition1 || !condition2 || !condition3)
  {
    continue;
  }
  
  // Do something

  if(!condition4 || !condition5 || !condition6)
  {
    continue;
  }

  // Do something else

  if(!condition7 || !condition8 || !condition9)
  {
    continue;
  }

  // etc
}

[ Voor 55% gewijzigd door GF op 05-01-2006 20:40 ]

[Peter]

Ik gebruik ook de opzet van Paul Nieuwkamp , imo is dat gewoon het meest duidelijke, en ondanks dat ik vaak de enige ben die in m'n code zit, is het wel zo prettig niet een half uur alles te hoeven bestuderen.

[Paul]

@GF: Ik heb in mijn voorbeeld toch ook al 9 condities in 1 if?
Dan gaat het nog steeds op Gewoon zoveel mogelijk in 1 if, en dan op gevoel (afhankelijk van de complexiteit/repeterende karakter/etc) al dan niet een paar naast elkaar

Zoals in jouw voorbeeld zou ik het waarschijnlijk ook doen. Ga je echter ipv een aantal booleans een aantal functies aanroepen die booleans retourneren (of je test de uitkomst met een variabele/magic number/constante/doe eens gek) dan zet ik ze al snel onder elkaar, met name om de verschillende condities uit elkaar te kunnen houden

@ hieronder: Ik heb het hier ook over je 2e voorbeeld

[ Voor 5% gewijzigd door Paul op 05-01-2006 21:45 ]

[GF]

Paul Nieuwkamp schreef op donderdag 05 januari 2006 @ 20:48:
@GF: Ik heb in mijn voorbeeld toch ook al 9 condities in 1 if?
Dan gaat het nog steeds op Gewoon zoveel mogelijk in 1 if, en dan op gevoel (afhankelijk van de complexiteit/repeterende karakter/etc) al dan niet een paar naast elkaar

Ben ik mee eens. Doe ik zelf ook. Misschien zelfs iets teveel aangezien sommige mensen die er naar kijken al snel de 'weg' kwijt zijn. Doelde eigenlijk op mijn 2e voorbeeld. 1e misschien niet zo goed. Al geeft het voor andere mensen misschien wel een beter idee hoe iets op te zetten

[riezebosch]

GF schreef op donderdag 05 januari 2006 @ 18:33:
[...]
Dit is ook typisch een voorbeeld van ranzigheid die ik erg vaak zie (vooral bij afgestudeerden van HIO Arnhem (wordt dat daar zo aangeleerd oid?)).

C#:

public bool DoSomething()
{
  try
  {
    string blaat = "0030";
    int example = Convert.ToInt32(blaat);

    return true;
  }
  catch(Exception ex)
  {
    return false;
  }
}

En dit gaat dan de hele applicatie door.

Heel vroeger zou ik dat ook zo gedaan hebben. Toen was ik echt eng van het opgooien van uitzonderingen. Vond het simpelweg returnen van een bool veel duidelijker, en als je meerdere foutcodes wilde gebruikte je gewoon een int. Het probleem daarbij is natuurlijk dat je ergens vast moet stellen wat de mogelijke returnwaarden zijn. Maar aan de andere kant wordt bij exceptions denk ik vaak de foutmelding in de exception gestopt, waardoor de errorreporting dus helemaal versnipperd raakt.

Laatste tijd heb ik niet zoveel meer met try/catches te maken gehad

[Serpie]

Bij het nalopen van een nieuw project kwam ik onderstaande code tegen, niet heel slecht maar "Return" wordt hier toch niet helemaal begrepen.

Visual Basic .NET:

    Friend ReadOnly Property ItemHasSubCollections() As Boolean
      Get
        If SubCollecties Is Nothing Then
          Return False
          Exit Property
        End If
        Return (SubCollecties.CountGet > 0)
      End Get
    End Property

[Erkens]

GF schreef op donderdag 05 januari 2006 @ 18:33:
Dit is ook typisch een voorbeeld van ranzigheid die ik erg vaak zie (vooral bij afgestudeerden van HIO Arnhem (wordt dat daar zo aangeleerd oid?)).

C#:

public bool DoSomething()
{
  try
  {
    string blaat = "0030";
    int example = Convert.ToInt32(blaat);

    return true;
  }
  catch(Exception ex)
  {
    return false;
  }
}

opzich is daar weinig mis mee, afhankelijk van de functie natuurlijk, je wilt niet altijd een exceptie opgooien, maar bijvoorbeeld een string converten naar integer indien mogelijk. De aanroepende functie hoeft zich dan niet druk te maken van eventuele excepties waarbij die alsnog die int op bijvoorbeeld 0 kan zetten. Of moet die ook de exceptie maar doorsturen tot je uiteindelijk bij je main terrecht komt?
Ergens moet je toch iets doen met die exceptie. Persoonlijk wil ik die het liefst zo snel mogelijk opgelost zien. Maar nog maals, dit is natuurlijk allemaal afhankelijk van het type exception en de functionaliteit die het moet hebben.

[GF]

riezebosch schreef op vrijdag 06 januari 2006 @ 01:22:
[...]

Heel vroeger zou ik dat ook zo gedaan hebben. Toen was ik echt eng van het opgooien van uitzonderingen. Vond het simpelweg returnen van een bool veel duidelijker, en als je meerdere foutcodes wilde gebruikte je gewoon een int. Het probleem daarbij is natuurlijk dat je ergens vast moet stellen wat de mogelijke returnwaarden zijn. Maar aan de andere kant wordt bij exceptions denk ik vaak de foutmelding in de exception gestopt, waardoor de errorreporting dus helemaal versnipperd raakt.

Laatste tijd heb ik niet zoveel meer met try/catches te maken gehad

In dat geval maak je een eigen exceptie klasse en voeg je een errorcode property toe. Dit is dan weer een enumeration waar je al je errors in definieert met een int als waarde. Dan kan je later deze filteren oid.

Erkens schreef op vrijdag 06 januari 2006 @ 09:00:
[...]

opzich is daar weinig mis mee, afhankelijk van de functie natuurlijk, je wilt niet altijd een exceptie opgooien, maar bijvoorbeeld een string converten naar integer indien mogelijk. De aanroepende functie hoeft zich dan niet druk te maken van eventuele excepties waarbij die alsnog die int op bijvoorbeeld 0 kan zetten. Of moet die ook de exceptie maar doorsturen tot je uiteindelijk bij je main terrecht komt?
Ergens moet je toch iets doen met die exceptie. Persoonlijk wil ik die het liefst zo snel mogelijk opgelost zien. Maar nog maals, dit is natuurlijk allemaal afhankelijk van het type exception en de functionaliteit die het moet hebben.

Dat wil je alleen op handelingen die je vaak moet doen en waarvan het je niet uitmaakt of het fout gaat de ja of de nee zolang er maar iets gereturnt wordt waar je wat mee kan. Voorbeeld is bij bij het uitlezen van een DirectoryEntry's property collection (LDAP object). Dan heb je de kans dat de attribuut niet bestaat of niet in het LDAP schema zit. In zo'n geval ga je natuurlijk niet voor iedere property die je wil uitlezen een try catch omheen gooien. Dan maak je idd 1 functie met interne exceptie handling. Als er iets fout gaat return je gewoon een lege string of 0 oid.

[killingdjef]

code:

try{
System.out.println ( heleNaam.getText(heleNaam.setText (naam.getText() + achterNaam.getText))));
}
catch{}

Bij wiskunde zeiden ze dat je een stap over mocht slaan bij het oplossen van "sommen" als je het snapte. Ik paste deze theorie ook toe tijdens mijn eerste programmeerles in Java en liet het met vol trots zien aan mijn leraar.

Met 1 regel moet je de king zijn!

Maar het enigste wat hij over zijn lippen kreeg was...
"Wat ben JIJ nou weer aan het doen?!? "

[killingdjef]

nog iets doms van mezelf wat ik herriner

code:

String[] noob;

noob[0] = 1;
noob[1] = 2;
noob[2] = 3;

etc.
Maar dat zijn zulke standaardfouten, die maakt iedereen in het begin als ze nog niet de magische for int i; i=0; i++ -statement ondekt hebben.

[prototype]

@GF:
Ik vind een continue eigenlijk alles behalve netjes, en eigenlijk al meer naar spaghetti code neigen, omdat de flow van je code er zo drastisch door verandert door te jumpen. Het lijken wel bijna GOTO's
Bij een aaneenschakelijk van dergelijke condities lijkt het mij niet geheel onverstandig om subcondities op te stellen die je misschien later in je code weer kan gebruiken, afhankelijk van of de staat van het object waar je naar queried wel of niet verandert is.

Java:

boolean hasValidName = condition1 && condition2 && condition3;
boolean hasValidAge  = condition4 && condition5 || condition6;

if (hasValidName && hasValidAge)
{
    //....
}

killingdjef schreef op zaterdag 07 januari 2006 @ 01:29:

code:

try{
System.out.println ( heleNaam.getText(heleNaam.setText (naam.getText() + achterNaam.getText))));
}
catch{}

Bij wiskunde zeiden ze dat je een stap over mocht slaan bij het oplossen van "sommen" als je het snapte. Ik paste deze theorie ook toe tijdens mijn eerste programmeerles in Java en liet het met vol trots zien aan mijn leraar.

Met 1 regel moet je de king zijn!

Maar het enigste wat hij over zijn lippen kreeg was...
"Wat ben JIJ nou weer aan het doen?!? "

Als je dat hier zou flikken bij de UT zou je corporale straf ondervinden Een lel om de oren dus. Het is om te beginnen al vrij 'apart' wat je doet door eerst iets te setten en vervolgens datzelfde weer met een query te pakken. Refactoren zou hierbij niet misstaan, en het is al helemaal flauw om een mogelijke exception niet af te handelen. Nee beter zou zijn:

Java:

String strHeleNaam = naam.getText() + achterNaam.getText();
heleNaam.setText(strHeleNaam);
System.out.println(strHeleNaam);

Uit semantische overwegingen zou naam overigens een ongelukkige 'benaming' zijn, voor wat je denk ik bedoelt als voornaam; voorNaam zou conformer zijn geweest

killingdjef schreef op zaterdag 07 januari 2006 @ 01:32:
nog iets doms van mezelf wat ik herriner

code:

String[] noob;

noob[0] = 1;
noob[1] = 2;
noob[2] = 3;

etc.
Maar dat zijn zulke standaardfouten, die maakt iedereen in het begin als ze nog niet de magische for int i; i=0; i++ -statement ondekt hebben.

Het verbaast me dat dit uberhaupt mag, ik bedoel, noob referenced naar null (je hebt nog niet new String[3]; gedaan en nog geen lengte meegegeven voor de array.)
Daar komt nog bij dat je opzich ook een assignment doet naar je String array waarvan als ik String[] noob niet gelezen zou hebben, zou zweren dat het om een integer array zou gaan. Natuurlijk werkt het wel door autoboxing, maar netjes is imho anders.

[ Voor 86% gewijzigd door prototype op 07-01-2006 03:05 ]

[Wim-Bart]

Verwijderd schreef op maandag 07 april 2003 @ 20:56:
Bovenstaande is wel niet altijd toepasbaar, maar hier mocht het dus wel.
Evenals hetvolgende die ik de leukste vind maar die blijkbaar wel veel toegepast wordt:

code:

xor %eax,%eax ;voor de leken: eax wordt hier op 0 gezet
inc %eax ; hier wordt er ééntje bij eax opgeteld, wat dus 1 geeft

kan vervangen worden door één instructie:

code:

movl    $1, %eax ;hier plaatst men 1 in eax wat veel efficiënter is dan voorgaande

scheelt weer een instructie, maar eigenlijk zijn er zo oneindig veel op te sommen, compilers zijn niet altijd efficiënt zo blijkt. Dan moeten we dat maar zelf optimaliseren.

Niet zoveel mis mee, maar op x86 genereerd de eerst 2 bytes code en jouw instructie genereerd 5 bytes code. Het eerste voorbeeld spreekt van genialiteit en kennis van de processor. De eerste wordt dan ook direct in de pijplijn van de processor afgehandeld en het tweede voorbeeld bevriest de integer pijplijn langer.

Vroeger veel in Turbo Pascal geprogrammeerd en Delphi 1. Daar had je gewoon shortstrings. Daar gebruikte ik wel eens code zoals dit:

code:

  { Als invoer langer is dan 10 letters afbreken }
  if ord(strInvoer[0])>10 then strInvoer[0]:=chr(10);

En dan moet je het eens porten naar longstrings :-)
Overigens was deze code verdomd snel.

Andere dirty code:

code:

  xor ax,ax
  mov bx,ax
  mov cx,ax
  mov dx,ax
  push ax
  push ax
  pop si
  pop di

[ Voor 19% gewijzigd door Wim-Bart op 07-01-2006 03:09 ]

[kenneth]

prototype schreef op zaterdag 07 januari 2006 @ 02:24:

Java:

String strHeleNaam = naam.getText() + achterNaam.getText();
heleNaam.setText(strHeleNaam);
System.out.println(strHeleNaam);

uitrArgh! bijvnwHongaarse znwNotatie

Het verbaast me dat dit uberhaupt mag, ik bedoel, noob referenced naar null (je hebt nog niet new String[3]; gedaan en nog geen lengte meegegeven voor de array.)
Daar komt nog bij dat je opzich ook een assignment doet naar je String array waarvan als ik String[] noob niet gelezen zou hebben, zou zweren dat het om een integer array zou gaan. Natuurlijk werkt het wel door autoboxing, maar netjes is imho anders.

Ik denk ook niet dat het mag, maar dat het punt was dat hij niet door de array itereerde met een for-lus

[Ivo]

code:

boolean hasValidAge  = condition4 && condition5 || condition6;

Dit zou ik ook nooit doen. Wat gebeurt hier nou?

code:

boolean hasValidAge  = (condition4 && condition5) || condition6;

of

code:

boolean hasValidAge  = condition4 && (condition5 || condition6);

Ik ken geen Java trouwens, dus misschien ligt het daaraan. Toch vind ik dat je dit soort dingen wat explicieter mag maken.

[RayNbow]

kenneth schreef op zaterdag 07 januari 2006 @ 09:34:
[...]
uitrArgh! bijvnwHongaarse znwNotatie

Wat is er mis met Hongaarse notatie? Ik gebruik het zelf wel eens, voor naamgeving van variabelen van GUI objecten bijvoorbeeld.

[kenneth]

Tsja, ik ben erg zelf ook niet consequent in ... Voor primitives doe ik het niet, maar voor componenten, collecties ed weer wel, CountryComboBox, InvoiceCollection ...
achja, zolang je maar consequent bent in je inconsequentie

[Jaap-Jan]

Ivo schreef op zaterdag 07 januari 2006 @ 11:55:
[...]

Dit zou ik ook nooit doen.

Heb je helemaal gelijk in, want het kan leiden tot verwarring, maar er zijn wel regels opgesteld over de prioriteit van operators, ook voor Java.

Wat gebeurt hier nou?

code:

boolean hasValidAge  = (condition4 && condition5) || condition6;

Dit gebeurt er, want een Conditional AND gaat voor een Conditional OR.

Zie bijvoorbeeld: Operator Precedence in Java

Ooh ja, of we gaan natuurlijk over op postfixnotatie :

code:

boolean hasValidAge  = condition4 condition5 && condition6 ||;

[ Voor 12% gewijzigd door Jaap-Jan op 07-01-2006 12:36 ]

[EfBe]

whoami schreef op Wednesday 04 January 2006 @ 12:28:
Waarom is dat dan semantisch hetzelfde als dat C#code voorbeeld ? Dat code voorbeeld gaat toch gewoon de exceptie doorgooien op de stack.
Echter, dit:

code:

try
{
   Bliep();
}
catch( Exception ex )
{
   throw ex;
}

is semantisch hetzelfde als:

code:

Bliep();

Hier ga je nl. geen exceptie opvangen, dus, deze wordt al automatisch doorgegooid.

Nee is niet hetzelfde.
Bij die brakke try/catch krijg je in je stacktrace als origin van de exception, de throw ex; regel. In de tweede de Bliep(); regel . Als er meerdere regels code in het try block staan heb je bij die eerste dus een probleem

_{C# kent geen throws statement}

nee maar wel een 'throw':
try
{
...
}
catch(Exception ex)
{
//handling code, logging oid.
throw;
}

[EfBe]

Janoz schreef op donderdag 05 januari 2006 @ 14:09:
Bij java wordt de stacktrace in de exception geplaatst bij het aanmaken van de exception. Wanneer je dezelfde exception weer opnieuw throwed wordt de stacktrace dus niet gewist. Bij .Net wordt de stacktrace blijkbaar door het throw commando gevuld (wat ik toch wat tegenstrijdig vind. Zal wel passen bij de 'we willen niks van onze internals laten zien' strategie van MS)

Nee, want ze hebben hun complete framework niet obfuscated dus dat is onzin.

throw existingObject
is identiek aan
throw new Exception();

omdat 'new Exception(); eerst wordt resolved, en dan de exception wordt gegooit mbv throw. het throw statement indien het een argument heeft (en hier heeft deze er een) dan zet deze zichzelf als startpoint. Daarom moet je ook throw zonder argument gebruiken. Lijkt me allemaal vrij logisch.

[EfBe]

GF schreef op Thursday 05 January 2006 @ 18:33:
Ook nuttig zo'n stuk code. Enige wat je hier uit kan afleiden is dat er een exceptie kan optreden. Welke? Vang alle mogelijke excepties apart op en maak geen gebruik van algemene exception classes. Dat vind ik toch zo ranzig

tja, maar er in een catch niets mee doen is onzin. Je kunt dan net zo goed de catch weglaten.

Voorbeeldje zoals het wel moet:

C#:

try
{
  string blaat = "0030";
  int example = Convert.ToInt32(blaat);
}
catch(FormatException)
{
  throw;
}
catch(OverflowException)
{
  throw;
}

Dit is toch onzinnige code? waarom die catches?

of

C#:

try
{
  string blaat = "0030";
  int example = Convert.ToInt32(blaat);
}
catch(FormatException ex)
{
  // do something with the exception like a dialog or something
}
catch(OverflowException ex)
{
  // do something with the exception like a dialog or something
}

In een method zou ik dit nog wel kunnen begrijpen, omdat je bv input data aan het processen bent en een default waarde van 0 hebt bv voor nietaanwezige input of fout geformuleerde input. Bij foute input kun je dus volstaan met een lege catch en die in een method stoppen zodat je je data processing code niet vervuild EN je verder kunt, want bij een exception kun je geen resume doen:

int customerID = SaveStringToInt(customerIDAsString, 0);

en:

C#:

public int SaveStringToInt(string value, int defaultValue)
{
    int toReturn = defaultValue;
    try
    {
        toReturn = Convert.ToInt32(value);
    }
    catch
    {
    }
    
    return toReturn;
}

In request.querystring processing code kom je dit nog wel eens tegen en helemaal niet verkeerd want het is de meest simpele en solide methode om dit te doen.

Nog een voorbeeld

C#:

foreach (Item item in items)
{
  if(condition1 && condition2 && condition3)
  {
    if(condition4 && condition5 && condition6)
    {
      if(condition7 && condition8 && condition9)
      {
        // do your thing
      }
    }
  }
}

Doe dit aub zo (oid.). Lees een stuk prettiger (ook voor jezelf)

C#:

foreach (Item item in items)
{
  if(!condition1 || !condition2 || !condition3)
  {
    continue;
  }
  
  if(!condition4 || !condition5 || !condition6)
  {
    continue;
  }

  if(!condition7 || !condition8 || !condition9)
  {
    continue;
  }

  // do your thing
}

Nee dat is een mindere oplossing. want de jouwe is veel minder leesbaar, want je code is niet opgezet als "ik doe 'do your thing' wanneer de volgende conditie waar is", en dus veel minder onderhoudbaar.

Gebruik continue alleen wanneer je in dit soort situaties zit:
for(...)
{

hier testen of je die 20 regels code inmoet, zo nee: continue

/*
20 regels code
*/
}

Jij gebruikt een not test in je if statement. Deze zijn moeilijker te onderhouden en niet alleen om de leesbaarheid. Een not test in een if statement is normaliter alleen logisch wanneer de not test de enige is om de waar conditie te formuleren om iets te doen.

Jouw code komt nl. neer op:
if(expr)
{
doe niets
}
else
{
doe wat je eigenlijk wilt
}

dit is brakke code want je weet nl. niet wat expr deed falen. Als dat iets is waar je in else mee uit de voeten moet ben je het haasje. Beter is te testen op wat WAAR moet zijn om wat je wilt doen ook te doen. En dat doen die 3 geneste if statements perfect. Ik zou er 1 expressie van maken, maar dat terzijde, ik kan begrijpen waarom er voor 3 geneste ifs gekozen is, om het leesbaar te houden. Ik bedoel, ik heb ook zo'n test:

C#:

/// <summary>
/// Determines if the field should be set to the value passed in.
/// </summary>
/// <param name="fieldToSet">Field to set.</param>
/// <param name="entityIsNew"><see langword="true"/> if [entity is new]; otherwise, <see langword="false"/>.</param>
/// <param name="value">Value.</param>
/// <returns>true if the field should be set with the value, false otherwise</returns>
internal static bool DetermineIfFieldShouldBeSet(IEntityFieldCore fieldToSet, bool entityIsNew, object value)
{
    // field value has to be updated in the following situations:
    // - when the entity is new and:
    //      - the field hasn't been changed
    //      - the field has been changed but the value is different, only if the current value is not null
    // - when the entity is not new and:
    //      - the field is already changed
    //      - the field's DbValue is null and value is not null
    //      - the field's DbValue is not null and the field's CurrentValue is different than the new value and not null
    //      - the field's CurrentValue is null
    return(
        (
            entityIsNew && 
            ( 
                !fieldToSet.IsChanged 
                ||
                (
                    fieldToSet.IsChanged 
                    && 
                    (
                        (
                            (fieldToSet.CurrentValue!=null) 
                            && 
                            !ValuesAreEqual(fieldToSet.CurrentValue, value)
                        )
                        ||
                        (fieldToSet.CurrentValue==null) 
                    )
                )
            )
        )
        ||
        (
            !entityIsNew 
            && 
            (
                fieldToSet.IsChanged 
                ||
                (
                    (fieldToSet.DbValue==null) 
                    && 
                    (value != null)
                ) 
                ||
                (fieldToSet.CurrentValue==null) 
                ||
                (
                    (fieldToSet.DbValue!=null) 
                    && 
                    (fieldToSet.CurrentValue!=null) 
                    && 
                    !ValuesAreEqual(fieldToSet.CurrentValue, value)
                )
            )
        )
    );
}

Die heb ik zo opgeschreven zodat het leesbaarder is, het is tenslotte geen code voor een obfuscation wedstrijd.

Om terug te komen op continue: continue is bedoeld om een loop opnieuw te starten wanneer je constateert dat de toestand waarin de locale data van de loop zich in moet bevinden niet de juiste is. Dit lijkt met jouw oplossing samen te vallen maar schijn bedriegt: continue in jouw situatie simplificeert de code niet. Je kunt bv met een enkele test kijken of je verder moet en of je daarmee grote if-else bomen kunt vermijdden verderop. Indien dat niet het geval is, vermijdt continue en doorloop gewoon de loop.

voorbeeld:

C#:

foreach(ActionQueueElement element in queueToPersist)
{
    bool saveSucceeded = true;
    IEntity2 entityToSave = (IEntity2)element.Entity;
    // do test if entity is really dirty. An entity can end up in the queue and not be marked dirty if the entity
    // had fk syncs pending (for example an entity which is an intermediate entity for an m:n relation, with solely fk fields)
    // and the PK syncs turned out to be not succesful, because the fk fields already contained that value.
    // if the entity turns out to be not dirty and not new, simply skip it and move on to the next one.
    if(!entityToSave.IsDirty && !entityToSave.IsNew)
    {
        // not changed nor new, no fields to update, skip
        continue;
    }

    IPredicateExpression updateRestriction = element.AdditionalUpdateFilter;
    TraceHelper.WriteIf(TraceHelper.PersistenceExecutionSwitch.TraceVerbose, ((EntityBase2)entityToSave).GetEntityDescription(TraceHelper.PersistenceExecutionSwitch.TraceVerbose, entityToSave), "Current persisted entity info");

    if(_isTransactionInProgress)
    {
        // add ourselves physically to the transaction so values will be rolled back when the transaction rolls back.
        AddTransactionParticipant(entityToSave);
    }
///.50 or more lines of code here...

Hier is de code van de loop niet simpeler wanneer ik daar neerzet:
if((entityToSave.IsDirty || entityToSave.IsNew)
{
// doe 75 regels code
}

ipv dat ik vooraf test of ik daar moet zijn, nee dus ga ik verder met de volgende in de rij (dit is een queue persister loop).

Wellicht onduidelijk voorbeeld, maar jouw 3 if statements met 3 continues vind ik niet beter, temeer omdat het meerdere tests zijn en de echte reden waarom de code moet worden uitgevoerd eigenlijk alleen maar onduidelijker maken. Jij moet nu echt gaan nadenken wat de conditie is wanneer 'do your thing' wordt uitgevoerd.

[prototype]

Ivo schreef op Saturday 07 January 2006 @ 11:55:
[...]

Dit zou ik ook nooit doen. Wat gebeurt hier nou?

code:

boolean hasValidAge  = (condition4 && condition5) || condition6;

of

code:

boolean hasValidAge  = condition4 && (condition5 || condition6);

Ik ken geen Java trouwens, dus misschien ligt het daaraan. Toch vind ik dat je dit soort dingen wat explicieter mag maken.

Een beetje vaardige coder met kennis van boolse algebra moet dit kunnen begrijpen en zo nee dan is haakjes toevoegen geen punt

[Michali]

@EfBe: Over die functie. Persoonlijk zou ik zoiets eerder oplossen met een enkele if statements en guard clauses. Je zou dan bijvoorbeeld iets als dit kunnen krijgen:

C#:

if ( entityIsNew )
{
    if ( !fieldToSet.IsChanged ) return true;
    if ( fieldToSet.CurrentValue==null ) return true;
    if ( !ValuesAreEqual(fieldToSet.CurrentValue, value) ) return true;
    return false;
}
else
{
    if ( fieldToSet.IsChanged || fieldToSet.CurrentValue==null ) return true;
    if ( fieldToSet.DbValue==null )
    {
        return value != null;
    }
    else
    {
        return fieldToSet.CurrentValue!=null && !ValuesAreEqual(fieldToSet.CurrentValue, value);
    }
}

Denk dat dat minder onderhoudbaar is? Persoonlijk vind ik het zo leesbaarder en overzichtelijker. Enkele checks zijn idd mischien iets lastiger te begrijpen, maar de gemiddelde progammeur moet daar geen problemen mee hebben denk ik.

[ Voor 3% gewijzigd door Michali op 07-01-2006 14:53 ]

[prototype]

@Michali:
Wat me meteen opvalt is het hard breken uit een compoundstatement en in dit geval uit een methode door een return statement. Dit verbreekt de flow van code en het is nogal lastig lezen imho doordat het in feite jumped. Het bufferen van wat je wil returnen in een auxilary boolean variabele, en vervolgens aan het einde van de methode 1 return statement met die variabele is imho leesbaarder.

[Michali]

Omdat deze functie toch puur een controle op iets is en dat returned is het in dit geval imo niet zo erg. Als je zeker weet wat het resultaat is kun je toch net zo goed de uitkomst returnen uit de functie?

Eigenlijk een goed voorbeeld van de refactoring.

[ Voor 29% gewijzigd door Michali op 07-01-2006 15:08 ]