# Post wrongly marked as duplicate

Here you can find a post wrongly marked as duplicate. Facts:

1. The code was rewritten for vb.net from vba, but initially was designed especially for vb.net. As a matter a fact, the code was initially written in vba because the help of excel's environment for necessary calculations. As a proof, @RubberDuck removed the excel tag from that post telling: "the object model is never referenced". Bellow that text I explain why did I used the excel tag and why did I chose vba to work with.
2. The vb.net code isn't exactly the same code, it was converted and adapted for vb.net and contains vb.net specific arguments. The code was compiled as vb.net as a part of a bigger project. Additionally, in order to cover various tasks in various projects, this part of code was designed as a standalone library.
3. For the sake of fairness, if you want to mark something as duplicate you have to mark as duplicate the initial vba code! As you can see reading the comments in initial vba code post very few people did really understand how can use that code, but the vb.net version of the code can be more attractive for site readers.
• Here you can find one more proof.. – Sorin GFS Dec 19 '15 at 22:39
• You didn't "rewrite" this for VB.Net, you slapped your VB6 code into a class and posted a new question without making any meaningful changes or improvements to the code. – RubberDuck Dec 19 '15 at 22:47
• You totally wrong here. I don't have any excel application made for that code, the application which is the code for... is in vb.net! See the link above. While I did the code in VBA I took care not to put anything incompatible with vb.net – Sorin GFS Dec 19 '15 at 22:53
• @RubberDuck you can try yourself, just "slap" the initial vba code into a class in visual studio... see what happens! – Sorin GFS Dec 19 '15 at 23:00
• You said yourself that the question is a duplicate. codereview.stackexchange.com/questions/114456/… – RubberDuck Dec 19 '15 at 23:02
• > the only difference is the language used: vb.net versus vba. I did post this using vb.net tag for those who are looking specifically for vb.net based code. – Sorin GFS 6 hours ago – RubberDuck Dec 19 '15 at 23:02
• Yes. How can be a duplicate a code made for another language? Read carefully that page, you can see that I made public the vb,net version as a reaction to Zak's comment. He didn't understand how the vba code can be used with excel, and as a response I said that... it isn't for excel! :) – Sorin GFS Dec 19 '15 at 23:06
• @RubberDuck, you removed my excel tag, lol, so even you made me to post the original purpose of the code: vb.net version! :) – Sorin GFS Dec 19 '15 at 23:09
• Because VB.Net was made to be (mostly) backwards compatible with VB6. That's how. However, a review in a .Net context would be a considerably different review from what you'd get in a VB6 context. So, maybe it's not a straight duplicate. Either way, are you sure you want this reopened? You're may not like the answers you're going to get. – RubberDuck Dec 19 '15 at 23:10
• I removed the excel tag because it didn't apply to the question... – RubberDuck Dec 19 '15 at 23:10
• Doesn't really matter for me if the post will be reopened or not. I'm not doing this for points, or for anything else. It's about how can others use or not a part of my work, it's about sharing. – Sorin GFS Dec 19 '15 at 23:12
• Then there's no reason to reopen it. If you wish to share your code, post it on GitHub. This site is for improving your code, not sharing it with the world. – RubberDuck Dec 19 '15 at 23:14
• Yes, you removed the tag correctly, I didn't said anything about it. But if it's not for excel, what it is for? :) – Sorin GFS Dec 19 '15 at 23:14
• I don't know, because you can just use the Enumerable class, and the Linq extension methods for Enumerable to do the job of the code you wrote. What is it for? – RubberDuck Dec 19 '15 at 23:16
• Ok, I'm not going to extend this any further, those methods aren't doing the same job. The fact is nobody didn't really tried to see what can be done with that code. Take just this: if it's not for excel... obviously it's for something else. – Sorin GFS Dec 19 '15 at 23:21

Of course it was compiled as VB.NET! Why did you closed the post before verify yourself that? Of course I disagree with closure! That code is part of much bigger project, and fits perfectly in it. The reason for looking the same code as the vba version is because the vba version was designed on purpose to be perfectly compatible with vb.net. And... its not the same! There are vb.net specific differences! So this is the method here: when somebody don't understand something he just proceed to cut it out? – Sorin GFS 5 hours ago

As the all-time top answerer in both and tags on this site, I think I know what I'm talking about when I say that your "VB.NET" code is VBA with enough lipstick to satisfy the .net compiler.

"VB.NET-specific differences" as you call them, aren't what @joranvar correctly identified in his answer.

I'm not going to review your code here, but this:

On Error Resume Next


And this:

LB = LBound(arr, selDim)
UB = UBound(arr, selDim)
ReDim seqArr(UB)


Is clearly VBA code imported into VB.NET. I would also like to quote @Zak's latest answer:

Though I will say: It's been 3 iterations and you're still using s and d as variable names for Data Arrays. Fix it.

This point is still valid on the 4th iteration. Reviewing someone's code and seeing that person post a "follow-up" question and completely ignore advice you've given in not one, not two, three answers already, is understandably irritating.

I know what you're after. You commented to that effect on October 3:

I assume all your critics. But, please, could we concentrate on functionality? – Sorin GFS Oct 3 at 13:28

What reviewers have been saying for 3 iterations, is that as external people looking at your code for the first time, they're having a hard time making sense of the single-letter identifiers and the meaningless variable names - code that's hard to read is hard to functionally improve because it's hard to follow. By ignoring the readability feedback you've been getting, you've basically worn your reviewers out, and posting a 4th iteration in VB.NET (to reach a new set of reviewers?) will not change anything: you will STILL get the SAME answers addressing your meaningless identifier names.

Same code, different tag, same answers - except, if reviewed as , it would literally get shredded for being VBA-with-lipstick, as it's not leveraging any of the .NET framework.

TL;DR: I stand by my close-as-dupe decision. Implement it in actual .NET code if you want it reviewed by a .NET crowd.

I don't see many differences between the two posts. The code is different, but only in places where the VB.Net compiler would complain about:

• Using Object instead of Variant.

• Removing Set where it is no longer allowed.

• Changing parameter name operator to operatorTag, as it is a reserved word.

• Removing On Error Resume Next.

The code makes up the largest part of the post, and it seems quite duplicate. Although I could see that a review based on VB.Net (pointing towards use the .Net framework) could be different from one based on VBA, the points from earlier reviews regarding style, naming and code reuse would still mostly be the same.

• Does it compile as vb.net? – Sorin GFS Dec 19 '15 at 23:24
• I don't have a VB.Net compiler handy. But I don't see whether that makes a difference (although it is a requirement for a valid post). Code review focuses on readability of the code, and that hasn't changed between the two posts. It may deal with performance and logical improvements, of which there has been no change between the posts. – joranvar Dec 19 '15 at 23:29
• To make the long story short, please read my point #3. – Sorin GFS Dec 19 '15 at 23:32
• Naturally, I did read your question before posting an answer. – joranvar Dec 19 '15 at 23:40