Introducing the for-if anti-pattern

re: Introducing the for-if anti-pattern

Joshua — Tue, 03 Jan 2012 01:59:20 GMT

[Trust me on this -- the code that used the for-if anti-pattern was not doing so because it was worried about short names. (The actual example was not a file system query but a database query.) -Raymond]

Filed under: completely missing the point (not Raymond, but everybody else). This changes just about everything.

re: Introducing the for-if anti-pattern

Gabe — Sat, 31 Dec 2011 06:39:03 GMT

Joshua: FindFirstFile always returns a long name along with the short name if it exists, and GetFiles just uses that behind the scenes.

As of W7 and WS2008R2, FindFirstFileEx can be passed FindExInfoBasic to have it not query the short names, so you can avoid the short names if your OS supports it.

re: Introducing the for-if anti-pattern

Jim — Sat, 31 Dec 2011 00:46:49 GMT

Re: short names (and maybe other related filesystem quirks)

Surely this is another problem with the for-if anti-pattern, rather than something it does right? I mean, if the filename is "longfi~1.txt" instead of "desktop.ini", presumably the intended behaviour would be that the routine succeeds, which the for-if anti-pattern doesn't. (And again, in this case it would be even better to "just go ahead and do it, and catch the exception if it doesn't work".)

Having said that, it does prove that there's a difference in behaviour, and so it's possible in principle that the for-if anti-pattern would have better results in some situations.

re: Introducing the for-if anti-pattern

Joshua — Fri, 30 Dec 2011 04:51:44 GMT

Phaeron above is right. Calling GetFiles() avoids short-name collisions as it won't return any short names.

Too bad there's no option to the wildcard expansion to FindFirstFile to avoid them. However, the way GetFiles() works, is it returns the long name for any file matching by shortname to wildcard (I don't know if Find*File always returns the long name or if .NET

makes another call) so simply repeating the match in the code fixes the problem.

re: Introducing the for-if anti-pattern

sambeet — Thu, 29 Dec 2011 18:29:15 GMT

I am not so sure that i can write this off as an absolute anti pattern. of course, if you are not breaking from the loop, it is a problem. But consider the coding / real life scenarios:

1. What if you are given a list and are asked to operate on a specific element. I cannot assume that the list is always hashed. Depending on the size of the list and / or frequency of execution of my logic, i may simply decide to iterate till i find the right item. I would not blindly assume that i need to hash the list every time because, hashing comes at the expense of additional memory and one time processing.

2. Going to your flavor logic, lets assume that all flavors are on the display and there is no server [this is a true representation of the concept]. Are you not going to go through the list till you see the flavour you want? NOW, lets assume the person being present at the counter. I do not have to spend time looking at an extensive menu display. i can simply ask the server. HERE, the server IS my hash in a way.

So, in sort, this is a bad practice but only if

1. if you own the list in your code

2. frequently need to operate on a specific element

3. Do not have member contract considerations to implement hashing

[Obviously not every enumeration falls into for-if anti-pattern. Only the ones where the container provides direct addressing. -Raymond]

re: Introducing the for-if anti-pattern

Chris B — Thu, 29 Dec 2011 15:15:33 GMT

"You also see this anti-pattern used in real life: 'What flavors do you have?' and then after the list of flavors is recited, 'I was hoping you had raspberry.'"

For-if might be a reasonable method in this case. The customer may believe that the odds of the provider having raspberry are low, and must therefore choose an alternative. If the provider's options are unknown and the odds are high that the entire list will need to be recited, it may not optimize the scenario to ask if raspberry is available before asking for the list. The customer may also be in a situation where raspberry sounds good now, but might hear something that sounds better (I can't think of a situation where this would happen in computing, but it works in this analogy).

You could also imagine scenarios where the customer had multiple preferred options; something like "I was hoping for raspberry, blueberry, or strawberry." Depending on what options are available to make that determination, it may be more efficient to just ask for the list and see if one of the preferred options is there. Doing so may even free the provider to service other requests while the customer is making a decision. This is fairly close to what happens when a server at a restaurant hands you a menu.

The questions I would try to answer before deciding on the best approach are:

1. How long are the customer and provider's lists?

2. How often do they change?

3. How often will each list need to be queried/compared?

4. What is the cost of communication between the customer and provider?

5. What methods does the provider support to answer the customer's questions?

re: Introducing the for-if anti-pattern

Raphael — Wed, 28 Dec 2011 21:23:09 GMT

Well, I can think of an Ada example where the for-case pattern makes sense. Since a case must include all values of a given type, doing a for over the full range of a type and then a case inside it would make sure to handle all values in that range.

re: Introducing the for-if anti-pattern

JM — Wed, 28 Dec 2011 16:34:24 GMT

"Regarding the question of using a dictionary to look up a value. That's all well and good if you already have a dictionary, but if all you have available is an array, then iterating through the array to find the one element you need to do something to will be quicker than building a dictionary in order to do one single lookup on it."

That goes without saying, so I didn't say it. Don't make me bring back the nitpicker's corner.

Wait, I don't have one and this isn't even my blog. Never mind.

re: Introducing the for-if anti-pattern

Nick Lowe — Wed, 28 Dec 2011 16:03:28 GMT

In addition to the race, the BCL's File.Exists() method is of limited value as it can only confirm that a file exists at a location, not that it does not exist. (It's the same with Directory.Exists().)

This is because File.Exists() does not discriminate between a file not existing and an underlying error condition that prevents the existence of a file being determined. It returns false in both cases.

What has been implemented is not Exists() semantics, it is IsAccessible() semantics, and only in the instant that you call it. You cannot assume that it is still accessible after due to the race.

So... just try and open the file and handle the FileNotFoundException exception.

So... just try and open the file and handle the exception.

re: Introducing the for-if anti-pattern

Nick Lowe — Wed, 28 Dec 2011 15:59:46 GMT

If you do want to see if a non-directory file exists in .NET as opposed to checking if it's accesible to the application:

public static bool FileExists(string path)

{

try

{

return (File.GetAttributes(path) & (FileAttributes.Directory | FileAttributes.Device)) == 0;

}

catch (FileNotFoundException)

{

return false;

}

And for a directory file:

public static bool DirectoryExists(string path)

{

try

{

return (File.GetAttributes(path) & FileAttributes.Directory) != 0;

}

catch(FileNotFoundException)

{

return false;

}