Hmmm.. the "case 1" and "case n" parts could go before or after the loop, and the loop would be from 2 to n-1. So no, in this case (pun wasn't intended, but is now) it's not necessary, but could be otherwise.

The point of the for/case antipattern is that it does something completely different on each iteration. It isn't simply "any case statement inside a loop", and anyone who thinks that's inherently bad without further context needs their head examined.

TRWTF is that if your going to be using matrix math, you should be using a tool designed specifically for matrix math. Like Matlab. Sure, you can do a lot of Engineering with Excel, but use the proper tool for the job please.

I'm with the guys who point out that the real problem with the solution isn't the "anti-pattern:" it's a failure to understand the abstractions involved. (Which can often lead to an anti-pattern, I suppose.)

The first thing I thought when I saw the "documenting comment" was, oh boy, I wonder what the requirement is. I mean, there must be some reason to need these data structures. And there's every reason to believe that they are part of a bigger requirement, which may not yet be obvious, but will no doubt develop in time.

The second thing I thought was "Oh, look, it's sort of an identity matrix, except it isn't quite." This leads to the numpy solution given above, because the clearest and most maintainable solution is to create an identity matrix of the appropriate dimension and then to use matrix manipulation to produce the desired result. That way you are operating on actual matrixes, not on some arbitrary loop of ones and zeros.

The slight problem with using either numpy or Matlab is that, well, this is a VB.Net environment, so those don't really help that much. However, if you google/stack-overflow for .NET matrix libraries, you should be able to find a reasonable fit. (I found several.)

Taken your comment to the logical conclusion then is not to create the matrix directly but in say, MATLAB, build the matrix with maketform('projective',...) or fitgeotrans or whatever, in which case the matrix is treated as an opaque operator. I find that a lot of programmers, versus engineers and scientists, have a knee-jerk reaction against this level of abstraction, in part because it requires a specialized environment that has as many of the tools you need as possible, Matlab or SciPy. But also because of the large level of disconnect between what they perceive as programming. (For example, Matlab matrices are not arrays, they're complex copy-on-write structures that are completely opaque but make a lot of operations, like transposing, O(1)). Ultimately, though it is the right tool for the majority of engineering-heavy small-scale problems.

I'd put it more simply in this case. 99% of programmers are not comfortable with matrix arithmetic. (I'm not particularly comfortable, for example.)

But my basic point is, if you are working in a domain where matrix transformations apply, then you are doing everybody else a disservice by not using matrix arithmetic in some way.

I mean, let's assume the product or project behind this thing uses eigenvectors or linear algorithms or any number of other things that are based upon matrix transforms. And let's assume that there are five or ten VB.Net programmers out there, each charged with a sub-task involving the implementation of one small part of what is essentially one, properly abstracted to the correct level, domain.

It isn't actually important that this one is an anti-pattern that obfuscates the abstractions inherent in the domain. It's important that there are five or ten other VB.Net programmers (in this case, the language is irrelevant) who are going to come up with five or ten completely separate and incompatible anti-patterns.

This is why I despise "clean code" freaks. Don't tackle the problem at the lowest level possible. Tackle it at the appropriate level, which is probably design and possible even architecture.

I'm not sure that this counts an example of the "for-case" antipattern. That antipattern usually implies that the loop has a fixed (small) number of iterations, and it does not save any effort at all, i.e. that you could fully unroll the loop and have the code be no more verbose than before. In other words, my understanding of the "for-case" antipattern is that it's only applicable for problems where a loop is unnecessary in the first place. That said, I can't remember the last time where a "for-case" was useful for anything other than processing some stream of data coming in from outside the process (e.g. event handlers, simple command line option parsing).

Anyway, I'm not really sure what the reason is for interleaving the definitions of the different variables in this example. I've hardly used any form of Visual Basic (and when I did it was over a decade ago), but aside from possible syntax errors, my "better" answer would have been something like the below. (The comments assume that these arrays are matrices for some linear algebra problem, which seems like a reasonable guess based on the function name, and the pattern mentioned in the comments.)

' e_1 is a vector of size n, consisting of a 1 followed by n-1 0s.
e_1 = NewArray(n, 1, 0#)
e_1(1, 1) = 1#
' e_n is similar, except that the last element is a 1 and the first element is 0.
e_n = NewArray(n, 1, 0#)
e_n(n, 1) = 1#
' n_1 is an n by n-1 sparse matrix, with 1s on the *sub*diagonal.
n_1 = NewArray(n, n - 1, 0#)
For i = 1 To n-1
n_1(i+1, i) = 1#
Next i
' n_n is also n by n-1 and sparse, but with 1s on the diagonal.
n_n = NewArray(n, n - 1, 0#)
For i = 1 To n-1
n_n(i, i) = 1#
Next i

The only duplication here is due to using two for loops, which you could easily combine if that really bothered you enough.

Seriously. I also sent this in via the link with my stuff attached just in case I win, but this is why that is a bad pattern.
TRWTFs: Doing things in loops that need to be done exactly once, Doing what is clearly going to be Matrix Math without a matrix library, thinking that there isn't a better solution, using variables to reference things that will never move (See their method for e_n using (i , 1) instead of just (1,1)),

Anything that can be done with For-Case can be done in other, better ways. There are times when it get shoehorned into an existing system because it's easy as heck to add and relatively easy to understand, but that doesn't make it good. If I'd been asked to review this code and it was in production, I would likely not have given more than a sideways glance. It isn't the worst anti-pattern in this case, but it is NOT good.

I like the fact that this example is written in an old enough version of VB to preclude the option of declaring 4 arrays with initializers. These arrays are small enough that they don't really need code to initialize them.