18 'For Each'es? If they all have at least some valued purpose in being there (i.e. they're not operating over singleton sets) then that means there's at least 2**18 calls to 'InsertRule'. That might take some time...

Why would you ever need a list of rules that include all permutations of 18 listboxes? If "Temp" in TempDel stands for Temporary, then that'll hardly be true, because that code block will take some time to execute...

We have something similar in our codebase, albeit in Java. Some fool discovers that you can turn pretty much anything into a list, and so makes the code "generic" by iterating over lists that are presently known to contain 1 item, but which might someday contain more.

18 'For Each'es? If they all have at least some valued purpose in being there (i.e. they're not operating over singleton sets) then that means there's at least 2**18 calls to 'InsertRule'. That might take some time...

2^18 is merely 262.144 inserts. Let one take 0.1 seconds then after some 7 hours your done saving them. Let there be one hour to choose the right combinations and you have WORKED AN ENTIRE DAY.

18 'For Each'es? If they all have at least some valued purpose in being there (i.e. they're not operating over singleton sets) then that means there's at least 2**18 calls to 'InsertRule'. That might take some time...

I can't decide which is worse... 18 levels of loops, or a function that takes 53 arguments... sure is purdy, though!

All that is missing is a comment trying to explain how it won't consume the CPU for days, it is of order Log(n), or how about "It's single threaded, so if you're on a multi-core machine, you'll be just fine."

Well, if you can for-loop over it like this, it already is an Iterable (otherwise it doesn't compile), so writing it like this makes more sense to me than "businessDays.getToday().get(0)". Then again, if there's some constraint that .getToday() is always a collection of 1, it should be typed directly as DayOfWeek instead of List.

18 'For Each'es? If they all have at least some valued purpose in being there (i.e. they're not operating over singleton sets) then that means there's at least 2**18 calls to 'InsertRule'. That might take some time...

2^18 is merely 262.144 inserts. Let one take 0.1 seconds then after some 7 hours your done saving them. Let there be one hour to choose the right combinations and you have WORKED AN ENTIRE DAY.

No, wait. Since the system will keep working during lunchtime, you should spend two hours choosing the right combinations.

For consistency, I always iterate the results of a database query, even if I'm only expecting one row. For example, if there are three customers with the same customer ID, I ship an identical order to all three of them.

What do you expect me to do? Randomly send everything to the first one? Design specs rarely address cases like this... (grumble...)

If anyone EVER says "oh, and the job will also include minor work in <insert legacy tech here>" then RUN AWAY. This always means "You came here thinking you'd work with cool new stuff, but instead we need a sucker^H^H^H^H^H^Hemployee to work on our legacy shit"

This kind of code reminds me of those houses you see around Christmas time...with all of the tackiest Big Lots decor they could find, haphazardly scattered around the yard, roof and wherever else the wind blows it.

It makes me wonder if the person behind it spent all day (possibly more..?)doing it...then stood back and looked at at it, letting out the contented "sigh" of a job well done, smiling while naively admiring the abominable crime against nature they have just created.

18 'For Each'es? If they all have at least some valued purpose in being there (i.e. they're not operating over singleton sets) then that means there's at least 2**18 calls to 'InsertRule'. That might take some time...

2^18 is merely 262.144 inserts. Let one take 0.1 seconds then after some 7 hours your done saving them. Let there be one hour to choose the right combinations and you have WORKED AN ENTIRE DAY.

... so that's 262.144 seconds and each one taking 0.1 seconds? or 0.100 seconds? is that equivalent to one tenth or one hundred?

I know you crazy europeans use the decimal point as a thousands seperator as well as a radix point, but wtf? :P

Talking Head:

The problem is the two spaces indent. If you only use one space, it won't be nested nearly so deep.

hahahaha, you win.

mucki:

O(n^^18), because sometimes P is almost NP :)

I believe this is generally known as O(scary) or O(mygod), or possibly in extreme cases O(wtf).

I know you crazy europeans use the decimal point as a thousands seperator as well as a radix point, but wtf? :P

Technically, the only European countries that use a decimal point (as opposed to decimal comma) are UK, Ireland and Switzerland.

However, it's easy for the rest of us to get things mixed up when trying to use the English notation. The fact that some computer applications are locale-aware and may expect a decimal comma, while others (notably programming languages) are locale-ignorant and always expect a decimal point, doesn't help.

To Ron's employer, and especially in the context of "job responsibly include... some maintenance of legacy VB6 applications", the word "some" tends to mean "pretty much all day long for the indefinite future."

The true WTF is that so many companies insist on maintaining vb6 apps instead of rightly dumping them for the garbage they are. I've had the displeasure of being forced to use many apps written in vb6 and none of them have been reliable. Just take a fresh RAID can to these buggy apps and call it a day.

Almost all of the list indexes on that function call are a constant 1 . It seems probable that most of those lists will ALWAYS have a single element on it - and the programmer knows it, because he would use variable list indexes otherwise.

Almost all of the list indexes on that function call are a constant 1 . It seems probable that most of those lists will ALWAYS have a single element on it - and the programmer knows it, because he would use variable list indexes otherwise.

Not quite. The lists have some unknown number of items, and each item has an unknown number of subitems, but the ziggurat only looks at the first subitem of each item...

You joke, but I've been there. I was working on someone else's code (not mine, I swear!) and having a hell of a time following it. So I ran it through a pretty-printer, with a one-space indent level. The innermost block of the main loop had more than 80 columns of leading whitespace. That's right, looping and control structures nested more than 80 deep.

And this was C++. Well, at least nominally. It compiled with a C++ compiler, anyway.

And yes, it was in a real product and was still that way when it went to market. If you must know, it was a game for the original PlayStation. And that's all I'm sayin', lest the Sony Hit Squad come after me.

It doesn't look so bad when you shrink the font size of that block of code to miniscule proportions...

See?

Thanks. Now every time I see a shell prompt, I'll imagine it's such a horror masked by small font, and lo(o)se my mind soon enough

Never mind that. To truly understand the significance of the code, you need to view it sideways. From one side, it is a bird of prey, screaming as it descends on your sanity. From the other, it is an alien invasion machine. You think you can disable it by uploading a virus, but if you do, the entire structure will collapse on your sanity.

The explanation is too freaking long to start, and we've already pointed out most of the flaws. The 58 arguments is definitely a WTF, and its a LOOOONG stretch that anybody realistically had to run the same function on all those collections. Even if he did, an error in one, will probably blow the next if they are not careful, so there is no way to tell what failed. The list goes on and on.