Bogdan Olteanu picked up a simple-sounding bug. There was a drop-down list in the application which was missing a few entries. Since this section of the app wasn't data-driven, that meant someone messed up when hard-coding the entries into the dropdown.
Bogdan was correct. Someone messed up, alright.
Destinatii = new List<Destinatii>(4);
for (int i = 0; i < Destinatii.Capacity; i++)
{
switch (i)
{
case 0: Destinatii.Add(new Destinatii { code = "ANGAJARE", description = "ANGAJARE" });
break;
case 1: Destinatii.Add(new Destinatii { code = "INSCRIERE", description = "ÎNSCRIERE" });
break;
case 2: Destinatii.Add(new Destinatii { code = "EXAMEN AUTO", description = "EXAMEN AUTO" });
break;
case 3: Destinatii.Add(new Destinatii { code = "SOMAJ", description = "SOMAJ" });
break;
case 4: Destinatii.Add(new Destinatii { code = "AJUTOR SOCIAL", description = "AJUTOR SOCIAL" });
break;
case 5: Destinatii.Add(new Destinatii { code = "TRATAMENT", description = "TRATAMENT" });
break;
case 6: Destinatii.Add(new Destinatii { code = "GRADINITA", description = "GRADINITA" });
break;
}
}
Once again, we have the fairly standard WTF of the loop-switch sequence, or the duffer device. Except this is dumber than even that, since there's absolutely no reason to do it this way. Normally, a loop-switch is meant to perform different behaviors on each iteration, here it just appends a value on each loop. This is an anti-pattern within the anti-pattern. They used the anti-pattern wrong! The case
s are irrelevant.
Well, mostly irrelevant. Combined with the loop condition, based on Destinatii.Capacity
, it's easy to understand why some values don't appear in the output.
Since you can initialize a list in .NET with a literal array, Bogdan went ahead and did that, replacing this block with essentially a one-liner.