• Greg (unregistered)

    Assumption. The mother of many a screwup.

  • Geoff J (unregistered)

    Never ASSuME! - It makes an ASS out of U and ME...

  • dpm (unregistered)

    30, 35, same thing.

  • GAZZA (unregistered)

    Hang on. Suppose fullList has, say, 16 items in it. The for loop is then:

    for (int i = 0; i < 16; i += 0)

    which is an infinite loop, is it not?

  • user2134234 (unregistered)

    I don't quite get this one. Tested with Java a list with 42 elements prints just fine, 16 elements indeed result in an infinite loop. Am I missing something here?

  • Discouraged (unregistered) in reply to user2134234

    You should look at the comment above yours. Remember, it's an integer division.

  • user2134234 (unregistered) in reply to Discouraged

    Yes I got that. So the problem is not really with the working items but with the list size here, which has got to be larger than 42.

  • TheDaveG (unregistered)

    TRWTF:

    "...they saw they were responsible for the change, so they assumed it must be good..."

    even though the code is, incredibly, actually, DOCUMENTED:

    // Get the FIRST 30 items for TEST

  • Dude (unregistered) in reply to GAZZA

    Looks like the story was changed after it was initially published. The story now talks about infinite loops with few items instead of missing items out of a large number of items.

  • Dave K (unregistered)

    Was this code written by Douglas Adams?

  • scragar (unregistered) in reply to user2134234

    Why 42?

    If I'm understanding the code correctly the if will complete as long as fullList.Count/35 is greater than zero, which is the case when fullList.Count >= 35, meaning that you need more than 34 items, not 42.

  • (nodebb) in reply to GAZZA

    Maybe it actually is,

    for (int i = 0; i < fullList.Count; i += fullList.Count%35) // Get the FIRST 30 items for TEST
    

    But neither way it would test the FIRST items...

    Btw, they seem to have increased the amount to 35 items.

    So it was clearly the client's fault for not noticing them they wanted to have 42 items in the list.

  • Guest Gast (unregistered)

    Doesn't that also start skipping every other item when there are over 70 of those? And skip two out of three when over 105, and so on...

  • Kashim (unregistered) in reply to Guest Gast

    What the code will actually do is give the user between 35 and 69 elements in their list, as long as their list has at least 35 elements. Anything less than 35 causes an infinite loop due to truncation on integer division. While this does technically make a list with thousands of items on it shrink to a manageable size, it doesn't do anything like what the comment said. For those of you who haven't worked it out, what the writer actually wanted was for (int i = 0; i < fullList.Count && i < 31; i++) // Get the FIRST 30 items for TEST However, TRWTF is that he didn't remove his testing code and, as a senior dev, no one else reviewed his code. Regardless of how he implemented that line, it is going to have a negative effect on the users if he leaves it in there.

  • (nodebb)

    If only .NET had some way to get the first thirty items. They might even call it something like [Take()](https://msdn.microsoft.com/en-us/library/bb503062.aspx)...

  • Carl Witthoft (google) in reply to Geoff J

    "assume" ? Get with modern times: https://xkcd.com/1339/ . And be sure to check out the title-text

  • foxyshadis (unregistered) in reply to PWolff

    It's quite hilarious how the "helpful" forum software mangles any comment with a less-than sign, not that you'd ever expect to see one of those on a programming forum. As always, TRWTF is TDWTF.

  • GAZZA (unregistered) in reply to Dude

    Well, that's sneaky. :)

    For anyone who is confused - when I wrote my reply, the story was talking about always only getting small numbers of items, even for a very large list; it seems that after my observation about the infinite loop they incorporated that into the text instead.

  • Falco20019 (unregistered) in reply to scragar

    Fun fact: As everyone knows, 034 (so 34 in octal system) converts to 42 in decimal system.

    I think the story was changed and first contained 42 instead of 35, otherwise a lot of the early comments wouldn't make any sense.

  • Falco20019 (unregistered) in reply to Falco20019

    Doh, swapped it around... 34 in decimal system is 042 in octal...

  • gnasher729 (unregistered)

    So anyone with fewer than 35 work items fell into an infinite loop, 35 to 69 was fine, 70 to 104 only showed every second work item, 105 to 139 every third... If this was the only one to complain, then everyone else must have had between 35 and 69 work items.

  • Curious (unregistered)

    This story makes no sense, neither în the original form I got through RSS, nor in the current form on the website. I'm starting to wonder if at least some of the stories are fictional.

  • jay (unregistered)

    Hey now guys, the story as written is POSSIBLE. As others have noted, a user with between 35 and 69 items would get an accurate list. Someone with 70 or more would get only part of his list, and someone with 34 or less would get an infinite loop. So if most users had between 35 and 69 items, they'd think the system worked. If users eliminate items from their list as they work them, they might not notice that they are getting a partial list. If, for example, you start out with 70, you only see half the items. Then you work one and remove it from the list. Now you have 69, and you see all the items. If you don't know when items are being added to your list, you could think, Oh, these new ones must have just been added recently. Depending on the ordering of the list, you might not notice that new items have been added between every pair of existing items. Etc.

  • (nodebb)

    t4est

    Addendum 2016-10-28 07:52: test2

  • (nodebb)

    Some will be fictional, some will be anonymised to buggery and might as well be fictional, and some will just be dogshit.

Leave a comment on “Work Items Incomplete”

Log In or post as a guest

Replying to comment #469041:

« Return to Article