Was doing some code review on a new .net 4.0 application and found the function below.

' This function takes in an SQL data reader and stores them in a datatable
Private Shared Function ConvertDataReaderToDataTable(ByVal reader As SqlDataReader) As DataTable
    ' Create new data table
    Dim schemaTable As DataTable = reader.GetSchemaTable
    Dim dataTable As DataTable = New DataTable
    Try

        If (Not (schemaTable) Is Nothing) Then
            ' A query returning records was executed
            Dim i As Integer = 0
            Do While (i < schemaTable.Rows.Count)
                Dim dataRow As DataRow = schemaTable.Rows(i)
                ' Create a column name that is unique in the data table
                Dim columnName As String = CType(dataRow("ColumnName"), String)
                ' Add the column definition to the data table
                Dim column As DataColumn = New DataColumn(columnName, CType(dataRow("DataType"), Type))
                dataTable.Columns.Add(column)
                i = i + 1
            Loop
            ' Fill the data table we just created

            While reader.Read
                Dim dataRow As DataRow = dataTable.NewRow
                i = 0
                Do While (i < reader.FieldCount)

                    If IsDBNull(reader.GetValue(i)) = False Then
                        dataRow(i) = reader.GetValue(i)
                    Else
                        Select Case reader.GetFieldType(i).Name
                            Case "boolean", "byte"
                                dataRow(i) = False
                            Case "int16", "int32", "decimal"
                                dataRow(i) = 0
                            Case "string"
                                dataRow(i) = ""
                            Case "datetime"
                                dataRow(i) = New DateTime
                            Case Else
                                dataRow(i) = ""
                        End Select
                    End If

                    i = i + 1
                Loop
                dataTable.Rows.Add(dataRow)
            End While
        Else
            ' No records were returned
            Return dataTable
        End If
        reader.Close()
    Catch ex As Exception
        Throw ex
    End Try
    Return dataTable
    dataTable = Nothing
    schemaTable = Nothing
End Function

Let's go over some of the wtf's:

1. Its a personal thing, but I hate it when people refuse to use the IsNot operator.  One of the upsides of vb is supposed to be that it's more human readable right? 
   "If schemaTable IsNot Nothing Then" just seems cleaner and easier to mentally parse.
2. Not inserting DBNull.Value when the value is actually null from the database.  Instead what he considers to be the "empty" values are inserted.
3. Not understanding that string comparisons are case sensitive so all null values are replaced with the empty string.
4. Having a try catch which does nothing but erase the stack trace (and no its not a place holder for future error handling).
5. Having statements after the final return statement.  I wonder if he just gave up in frustation when he couldn't get to those break points.  "Stupid debugger!  This is why I just use logging!"
6. Thinking he needs to help with the garbage collection by setting the datatables to nothing right before he leaves the function.
7. For those unfamiliar with .net this entire function can be replaced with dataTable.Load(reader).  The .net library has been able to load tables for you since .net 2.0 (2005).
8. This guy has a masters in CS and is still lacking some fundamental programming concepts.

Wow... You did miss "using a do-while loop where a for loop would be much more appropriate" :) Also, I'm not 100% sure about this, but wouldn't the Not (schemaTable) Is Nothing part actually attempt to Not the schemaTable, since it's in parentheses? What you get when you apply boolean operations to a DataTable is beyond me...

VB needs a new command: "But First..." which starts a block of code you meant to have happen. The block can be closed with the statement "Ok Now Do It".

As in:

Return myanswer

But First

   ' Do something to make sure myanswer isn't null.

   if IsNull(myanswer) then

     ' Oops

     myanswer = ""

   end if

Ok Now Do It.

Peraninth:

One of the upsides of vb is supposed to be that it's more human readable right?

And one if the downsides is that it fails miserably at that. The punctuation used in C# (the languages compile to the same AST with most differences being just different keywords and symbols) is visually more distinctive and thus easier to read quickly and the capital letters usually used all over the place in VB (they don't have to as it's case insensitive; Microsoft just seems possessed with capital letters) just make matters worse. After all, lower case letters are used in text, because they are more readable.

Bulb:

Peraninth:

One of the upsides of vb is supposed to be that it's more human readable right?

And one if the downsides is that it fails miserably at that. The punctuation used in C# (the languages compile to the same AST with most differences being just different keywords and symbols) is visually more distinctive and thus easier to read quickly and the capital letters usually used all over the place in VB (they don't have to as it's case insensitive; Microsoft just seems possessed with capital letters) just make matters worse. After all, lower case letters are used in text, because they are more readable.

Totally agree - VB is much less readable than C# simply because the bits of information you need to get at are floating around in a sea of keywords which look very similar. In C#, you have the items that represent class and function structure as symbols...but in VB they are a mishmash of keywords

It's like trying to play Where's Wally when all the other characters are wearing white and red stripey jumpers and a bobble hat.

Also I think the default colour scheme in C# is better than the VB one, so I don't get why anyone would rather write in VB? Is it for the implicit conversion? Casting in VB is also horrid looking.

LOLCat.NET is more humanly readable than VB, and .NET has been able to load a table from a query ever since 1.0.

Peraninth:

"If schemaTable IsNot Nothing Then"

 

Hmm, didn't know that keyword. I'll try it out, and maybe I'll hate VB.Net a fraction less. I'm used to having a negate operator in the comparison, just like every single other language uses.

I need if A != B && b==c.... 

I have to end up wasting time by going if A Not... wait, shit, this is VB, backspace, backspace, backspace, erase the whole fucking things start again

if Not A = B AndAlso... wait, shit, who knows how VB will actually evaluate this, arrow keys, parenthesis... arrow keys, parenthesis...

if (Not A = B) AndAlso (B == C) Then   Unknown symbol? Goddamn fucking VB!

 

 

Peraninth:

Not inserting DBNull.Value when the value is actually null from the database

Double-so for datetime values.  "So did this client confirm his registration today, or has he not confirmed it at all?"

Oh oh oh I know. With every SELECT statement, you can include a custom column:

 SELECT
      my_registration_datetime,
     CASE WHEN my_registration_datetime is null THEN 1 ELSE 0 END as my_registration_datetime_flag

Renan:

LOLCat.NET is more humanly readable than VB, and .NET has been able to load a table from a query ever since 1.0.

I don't really get the hate that vb.net receives.  I come from a a C/C++ background but I love the fact that it's not case sensitive and does some implicit conversion of the simple stuff for me.  It annoys me when I switch over to C# and have to type every .tostring call.  Oh wait, forgot it's C#.  The compiler is being a picky bitch and won't auto correct that to .ToString for me.

 I thought .net might have been able to do it since then but when I went to the MSDN page the docs only went back to 2.0 so that's what I went with.

Lorne Kates:

I need if A != B && b==c....

Well that's easy: if A <> B then.

Peraninth:

Renan:

LOLCat.NET is more humanly readable than VB, and .NET has been able to load a table from a query ever since 1.0.

I don't really get the hate that vb.net receives.  I come from a a C/C++ background but I love the fact that it's not case sensitive and does some implicit conversion of the simple stuff for me.  It annoys me when I switch over to C# and have to type every .tostring call.  Oh wait, forgot it's C#.  The compiler is being a picky bitch and won't auto correct that to .ToString for me.

 I thought .net might have been able to do it since then but when I went to the MSDN page the docs only went back to 2.0 so that's what I went with.

Lorne Kates:

I need if A != B && b==c....

Well that's easy: if A <> B then.

 

Nice troll.

I'd be willing to bet a developer who is too lazy to hold down the shift key while typing the letter 't' is probably also too lazy to think something all the way through before coding it.

ShatteredArm:

Nice troll.

I'd be willing to bet a developer who is too lazy to hold down the shift key while typing the letter 't' is probably also too lazy to think something all the way through before coding it.

I'd be willing to bet a developer who is too lazy to write out everything in machine code and instead relies on a compiler is probably also too lazy to think something all the way through before coding it.

Because, God knows, the quality of a language is measured in the quantity of boilerplate code it requires you to write. Hence why Java is the best programming language ever, by an order of magnitude.

Peraninth:

I don't really get the hate that vb.net receives.  I come from a a C/C++ background but I love the fact that it's not case sensitive and does some implicit conversion of the simple stuff for me.

Doesn't the whole "I'll just guess what you want me to do here" scare you?  I'd rather say "no, I don't want to tostring this because I want to actually add the numbers, and not contact the string.

Peraninth:

It annoys me when I switch over to C# and have to type every .tostring call.

Why are you ToString()ing everything?  From that statement, I'm guessing you're a big fan of the Stringly-Typed pattern?  Why deal with everything as a string.  C# gives you type-safety OOTB, whereas VB.Net would perform casts and other "magic" on my code.  I'd rather get a build error saying "I couldn't infer what the fuck you meant" and fix it at build-time vs getting a runtime error.

Peraninth:

Oh wait, forgot it's C#.  The compiler is being a picky bitch and won't auto correct that to .ToString for me.

Auto-correct?  That isn't the compilers job.  Even in C#, the compiler (well, really the C#-to-CIL interpreter) will implicitly cast certain types, as long as it's a widening cast and you aren't going to lose precision.  I'd rather know that what I'm doing is potentiall dangerous and could result in lost data or overflows.  It's really not that much harder or more work, is it?

Peraninth:

The compiler is being a picky bitch and won't auto correct that to .ToString for me

 

Fuckballs to that. I only recently noticed VB.Net actually allows you to conveniently forget to put brackets around empty methods.

Dim o as Object = SomeObject.ToString

Notice the lack of brackets:  .ToString()

How the living fuck am I supposed to tell if o now contains the string version of SomeObject, or a reference to the ToString method of SomeObject.

Oh, right, yet another vb.net "friendly" keyword-- AddressOf-- and even then, who the fuck knows?

Let me guess, you write code like this:

Damn Your Spleen!:

If DateTime.Now.ToString().Split("/")(3) = "2012" Then

    Response.Write("<font color=" & Char(34) & "purple" & Char(34) & ">Holy shit the Mayans!!1!</font>")

End If

 

ekolis:

Also, I'm not 100% sure about this, but wouldn't the Not (schemaTable) Is Nothing part actually attempt to Not the schemaTable, since it's in parentheses? What you get when you apply boolean operations to a DataTable is beyond me...

 I actually was curious about this too and it turns out that the parens around schemaTable don't end up doing anything.  SchemaTable is not evaluated at all in the parens but is essentially returned from the parens.  From there order of operations takes over and the code works as intended.

RichP:

VB needs a new command: "But First..." which starts a block of code you meant to have happen. The block can be closed with the statement "Ok Now Do It".

The sad part is I'm sure several of my coworkers would use this.  The conversation would go like this:

Me: "Why are you doing it like this?"

Them: "We needed it to do this stuff before it did that other stuff."

Me: "You know this is a solved problem in procedural programming right?  If you want something to happen first you just fucking type it first in the function.  A;SLDKFJASDL;FKJSDA!"

C-Octothorpe:

Doesn't the whole "I'll just guess what you want me to do here" scare you? I'd rather say "no, I don't want to tostring this because I want to actually add the numbers, and not contact the string.

It did at first.  But that's why I don't rely on it for anything but simple conversions (which is about all it will let you use it for anyway).  I can honestly say after 4 years of using vb.net I have not had a conversion bug caused by incorrect implicit conversions. It just gets it right.  You also aren't forced to use the implicit conversion you can tell it exactly how the fuck you want it to handle the conversion.

C-Octothorpe:

Why are you ToString()ing everything? From that statement, I'm guessing you're a big fan of the Stringly-Typed pattern? Why deal with everything as a string. C# gives you type-safety OOTB, whereas VB.Net would perform casts and other "magic" on my code. I'd rather get a build error saying "I couldn't infer what the fuck you meant" and fix it at build-time vs getting a runtime error.

The opposite actually.  The stringly-typed pattern really annoys me.  But when putting data into the text fields of labels, literals, and other html elements it should know what I'm talking about.  After all, every object in the .net world comes with a free .tostring method.  And yes you can have classes that the .tostring method wont really do anything usefull unless you override it, but on basic data types how can it get the conversion to strings wrong? 

eg:

double answer = 3;
label.Text = answer;  //please let me do this!

C-Octothorpe:

Auto-correct? That isn't the compilers job. Even in C#, the compiler (well, really the C#-to-CIL interpreter) will implicitly cast certain types, as long as it's a widening cast and you aren't going to lose precision. I'd rather know that what I'm doing is potentiall dangerous and could result in lost data or overflows. It's really not that much harder or more work, is it?

By auto-correct I'm talking about the capitalization of functions, variables, etc.  VB.net is case insensitive, but you can still use capital letters for a reason.  So I can be lazy when I am typing the names of already defined functions/variables but still follow coding conventions when defining functions if say all functions are supposed to start with a capital letter. And the day I find someone who is overloading .net functions in C# with lowercase versions of the same function is the day I go to jail for stabbing someone in the face.

Peraninth:

eg:

double answer = 3;
label.Text = answer;  //please let me do this!

Even if strict typing wasn't an issue, internationalization would be. You can't convert the int "3" to a string (at least not one displayed on the screen) without knowing what regional settings to use for the conversion. And you haven't provided that.

Don't assume US English. Bad programmer. Bad.

Peraninth:

The opposite actually.  The stringly-typed pattern really annoys me.  But when putting data into the text fields of labels, literals, and other html elements it should know what I'm talking about.  After all, every object in the .net world comes with a free .tostring method.  And yes you can have classes that the .tostring method wont really do anything usefull unless you override it, but on basic data types how can it get the conversion to strings wrong? 

Yeah, that used to piss me off too, but there are several databinding methods that can take care of this for you.

Peraninth:

By auto-correct I'm talking about the capitalization of functions, variables, etc.

Again, that's the IDE.  Since you're using VB.Net I'm assuming you're also using some version of Visual Studio, which has intellisense.  I find that it reduces 60-70% of my keystrokes and also takes care of spelling and capitalizing things like ReallyLongPropertyOrMethodNames.

Peraninth:

And the day I find someone who is overloading .net functions in C# with lowercase versions of the same function is the day I go to jail for stabbing someone in the face.

Agreed.  I'd help you get rid of the body.

blakeyrat:

You can't convert the int "3" to a string without knowing what regional settings to use for the conversion

 

How would and explicit ToString() (without arguments) help here at all?

dhromed:

blakeyrat:

You can't convert the int "3" to a string without knowing what regional settings to use for the conversion

How would and explicit ToString() (without arguments) help here at all?

It wouldn't. What's your point?

If I had my way, VS would have a warning for using an locale-less ToString() to put text into a UI element, but I understand how that would be hard to implement. It's still a bug though.

blakeyrat:

Even if strict typing wasn't an issue, internationalization would be. You can't convert the int "3" to a string (at least not one displayed on the screen) without knowing what regional settings to use for the conversion.

<Pedant>Actually, that's localization, not internationalization.</Pedant>

morbiuswilters:

<Pedant>Actually, that's localization, not internationalization.</Pedant>

Hey look, I get to re-establish my favorite tag:

RichP:

VB needs a new command: "But First..." which starts a block of code you meant to have happen. The block can be closed with the statement "Ok Now Do It".

As in:

Return myanswer

But First

   ' Do something to make sure myanswer isn't null.

   if IsNull(myanswer) then

     ' Oops

     myanswer = ""

   end if

Ok Now Do It.

Congratulations, you just invented Perl!

 

Lorne Kates:

Peraninth:

The compiler is being a picky bitch and won't auto correct that to .ToString for me

 

Fuckballs to that. I only recently noticed VB.Net actually allows you to conveniently forget to put brackets around empty methods.

Dim o as Object = SomeObject.ToString

Notice the lack of brackets:  .ToString()

How the living fuck am I supposed to tell if o now contains the string version of SomeObject, or a reference to the ToString method of SomeObject.

Oh, right, yet another vb.net "friendly" keyword-- AddressOf-- and even then, who the fuck knows?

Let me guess, you write code like this:

Damn Your Spleen!:

If DateTime.Now.ToString().Split("/")(3) = "2012" Then

    Response.Write("<font color=" & Char(34) & "purple" & Char(34) & ">Holy shit the Mayans!!1!</font>")

End If

 If you define a custom method with no parameters in a code behind page and try to call it in the same file, it will auto add the parens.  I believe it is only when you call a parameterless method that is part of an instantiated class/object that it doesn't require the parens.

eg:

DoStuff()
thing.DoStuff

I'm Ok with this. For the most part, what does it matter if DoStuff is a parameterless method or a property of thing? It is clear to me Lorne that vb.net touched you in a bad place when you were young. I'm sorry.

C-Octothorpe:

Again, that's the IDE. Since you're using VB.Net I'm assuming you're also using some version of Visual Studio, which has intellisense. I find that it reduces 60-70% of my keystrokes and also takes care of spelling and capitalizing things like ReallyLongPropertyOrMethodNames.

You're right.  I meant the IDE.  I shed a tear for anyone who is writing C# or vb.net in anything other than Visual Studio. So take all my capital letter auto-fixing complaints in the light that I am programming in Visual Studio.  Sometimes I worry if I have become too dependent on the auto-complete.  What will I do if I ever switch back to development on Linux and emacs????

blakeyrat:

Don't assume US English. Bad programmer. Bad.

I don't get this one either.  Not every website/application has localization requirements.  It would annoy me and waste time/money if every internal web app I made I had to deal with localization.  If they can't speak english they wouldn't be working here.

Peraninth:

blakeyrat:

Don't assume US English. Bad programmer. Bad.

I don't get this one either.  Not every website/application has localization requirements.  It would annoy me and waste time/money if every internal web app I made I had to deal with localization.  If they can't speak english they wouldn't be working here.

Note that blakey does analytics for the web and his pet peeve is about usability.  For one off corprate thingys you are right that doing it the wrong way is the cost effective way, but that doesn't make it the right way to be doing things.

Lorne Kates:

Damn Your Spleen!:

If DateTime.Now.ToString().Split("/")(3) = "2012" Then

    Response.Write("<font color=" & Char(34) & "purple" & Char(34) & ">Holy shit the Mayans!!1!</font>")

End If

 

 Actually, I believe that call can be written: Response.Write("<font color=""purple"">Holy shit the Mayans!!1!</font>")

 

Peraninth:

It would annoy me and waste time/money if every internal web app I made I had to deal with localization.

It's not too difficult - most cases it's just a matter of dropping a constant here and there as a text placeholder, and including a file full of constants defined to that locale's particular language. I agree keeping all the language files in sync can be a bit of work, but it focusses you as to the content and meaning of text displayed to the user.

From a useability POV, each time I've encountered "send message to user" actions in a design I'm working on, I'd prefer to drop in a placeholder representing an "item not found in catalogue" error and delegate the actual content to someone else (or deal with it later). It certainly made some PHP much cleaner to code.

locallunatic:

For one off corprate thingys you are right that doing it the wrong way is the cost effective way, but that doesn't make it the right way to be doing things.

Yes it does. Or, more accurately, it may. How is a cost-ineffective way of doing things you know you will never need the "right way"? The "right way"* varies by situation; not every situation calls for localization/internationalization.

*In fact, I find the phrases "right way" and "wrong way" to be loaded. A better terminology might be "better way" and "worse way".

morbiuswilters:

*In fact, I find the phrases "right way" and "wrong way" to be loaded. The right terminology might be "better way" and "worse way".

FTFY

morbiuswilters:

locallunatic:

For one off corprate thingys you are right that doing it the wrong way is the cost effective way, but that doesn't make it the right way to be doing things.

Yes it does. Or, more accurately, it may.

I think of it more as the wrong way may still be good enough.  Of course I'm constantly doing things in 'good enough' ways due to how my company accounts for things.

locallunatic:

For one off corprate thingys you are right that doing it the wrong way is the cost effective way, but that doesn't make it the right way to be doing things.

It may not, but it makes it the cost-effective way, which is what someone has decided, so is deemed to be "right" since it agrees with their decision. 

 

morbiuswilters:

*In fact, I find the phrases "right way" and "wrong way" to be loaded. A better terminology might be "better way" and "worse way".

This is going to sound like PHB tree-hugging bollocks, but I've been viewing things in terms of "the expensive way" and "the cheap way" for some years now. I no longer look at decisions in terms of right and wrong, more in terms of cost[1] and outcomes.

[1] for cost, not necessarily financial - think effort, manpower, resource consumption, etc.

Cassidy:

morbiuswilters:

*In fact, I find the phrases "right way" and "wrong way" to be loaded. A better terminology might be "better way" and "worse way".

This is going to sound like PHB tree-hugging bollocks, but I've been viewing things in terms of "the expensive way" and "the cheap way" for some years now. I no longer look at decisions in terms of right and wrong, more in terms of cost[1] and outcomes.

[1] for cost, not necessarily financial - think effort, manpower, resource consumption, etc.

Cost-benefit analysis, a fine way to make decisions. The point is, you should be asking what is necessary and optimal for your given situation, not simply following a binary system of right and wrong. That's what engineering is about.

locallunatic:

I think of it more as the wrong way may still be good enough.

If it's good enough, then it's not really the wrong way. This false dichotomy of right vs. wrong is a flawed way of approaching software engineering. It reeks of cargo cult behavior.

If a piece of software doesn't need internationalization/localization--and never will need it--then it pointless to build it in and only adds to code bloat. There are plenty of other examples of where this right vs. wrong dichotomy breaks down (OOP, MVC, etc.).

The closest thing to a right way of doing things is the way which fulfills the current (and likely future) requirements cheaply and effectively. That's all.

blakeyrat:

Even if strict typing wasn't an issue, internationalization would be. You can't convert the int "3" to a string (at least not one displayed on the screen) without knowing what regional settings to use for the conversion. And you haven't provided that.

Don't assume US English. Bad programmer. Bad.

It's actually future-proofing the code. Eventually the US will nuke everyone else and establish the Final Reich, eliminating the need for region settings. Heil to the Chief!

Cassidy:

This is going to sound like PHB tree-hugging bollocks, but I've been viewing things in terms of "the expensive way" and "the cheap way" for some years now. I no longer look at decisions in terms of right and wrong, more in terms of cost[1] and outcomes. I have become jaded and apathetical, devoid of love for the craft.

 

There. All better.

dhromed:

Cassidy:

This is going to sound like PHB tree-hugging bollocks, but I've been viewing things in terms of "the expensive way" and "the cheap way" for some years now. I no longer look at decisions in terms of right and wrong, more in terms of cost[1] and outcomes. I have become jaded and apathetical, devoid of love for the craft.

 

There. All better.

Anyone who still finds joy in software development is a naive scoundrel.

morbiuswilters:

Anyone who still finds joy in software development is a naive scoundrel.

<obi-wan>They are young and unjaded. Were we any different when we were their age?</kenobi>

dhromed:

There. All better.

Oh, I still have love for the craft. But I've seen the craft lusted over, adolescently groped, gang-banged and drunkenly raped so often, I've passed the point of embitteredness and ruefully accepted that the cycle will repeat again. I just don't want to be there when it re-occurs.

morbiuswilters:

Anyone who still finds joy in software development is a naive scoundrel.

 

I have an inkling of faith that there is some joy left in that colourful domain of game programming. A last refuge of sparkly code. A Bastion, if you will. Although that particualr gameplay style did not tickle my fancy and I have since removed the demo.

dhromed:

I have an inkling of faith that there is some joy left in that colourful domain of game programming.

Not in commercial game development for big titles. Those in the industry tell stories of sweatshop developer culture, mixed in with a veritable lashing of dictatorial mismanagement and WTFey project manglement (read: unreal constraints and pressure by the metric fucktonne).

It's no bed of roses. Sorry to have taken that inkling and crushed it between a leather-clad fingerpinch, but I found your misguided faith strangely disturbing.

dhromed:

I have an inkling of faith that there is some joy left in that colourful domain of game programming. A last refuge of sparkly code. A Bastion, if you will.

Oh, I do so love crushing hopes and dreams, I really do! Game development is as close to white slavery as you'll find.

 You cannot take away my hope!

dhromed:

 You cannot take away my hope!

I got out of games programming in the early '90s, which was the last point at which it was any fun.  Once it had become clear that there was serious money in the industry, the suits moved in and the life got drained out of it.

 

Until recently.  Indie mobile games development looks like bringing back the era of the bedroom / small team games coder.

DaveK:

Until recently.

 

*LATCH*

dhromed:

DaveK:

Until recently.

 

*LATCH*

Is that like a suckling kind of LATCH, or a hugging kind of LATCH?  Either way, get a fucking room...

C-Octothorpe:

dhromed:

DaveK:

Until recently.

 

*LATCH*

Is that like a RS kind of LATCH, or a DQ kind of LATCH? 

ObTopic'd that for you!

 VB vs C#

I've spent a lot of time working in VB since ye olden versions before .net mainly cus I did a lot of UI stuff and no serious number crunching that required me to work in C, when I had to work at a lower level on embedded devices the project was usually so small I could knock it up in asm so for many years I strangely avoiding actually programming in any form of C although occasionally had to debug others. Obviously this took time because not doing it day to day I'd always be thinking things like ... 'what does that ^ operator do, I can't remember'.

So now, when I find myself in the world of .net I tend to use VB because I've spent years getting familiar with its syntax and rules. Obviously VB in .net is a completely different language to the 3-6 I started out on and works completely differently, its better alright but I still had to re-learn a lot of things when I started using it. Old VB tried to be just that, BASIC, with a bit of 'Visual' chucked in. .net has changed all of that and I think perhaps foolishly kept VB, perhaps just to help move dodgy old VB people like me into the present?

Anyway this isn't what I came to post about... there is still one thing that gets me about VB, bloody arrays. Dim bollocks(64) as Byte... gives me an array with 65 elements indexed 0 to 64. Perhaps this is because in older versions they wanted to keep things simple for people who couldn't handle a 0 index and like everything to start at 1 in there code, I seem to remember that you used to have the option in old school VB to make arrays indexed from 1 and not have a zero... hell it may still be in .net and I just don't use it. Now that is fine, you'd dimension an array with '64' and get 64, numbered 1-64, but having the option to start at 0.. or maybe not complicates it. I like 0, zero is my friend, I've always used 0 and just accepted that with VB I have to specify the final index of the array, not the number of elements.

Problem is now I work between VB .net, someone elses C++ and some raw C code for embedded devices.

More than once I have cocked something up by forgetting the difference between arrays in C and arrays in VB, ending up with one too many or not enough depening on which head I used in which window. GAH.

 

I have to agree.  The array size declaration is very annoying.

Peraninth:

C-Octothorpe:

Doesn't the whole "I'll just guess what you want me to do here" scare you? I'd rather say "no, I don't want to tostring this because I want to actually add the numbers, and not contact the string.

It did at first.  But that's why I don't rely on it for anything but simple conversions (which is about all it will let you use it for anyway).  I can honestly say after 4 years of using vb.net I have not yet found a conversion bug caused by incorrect implicit conversions. It just gets it right.  You also aren't forced to use the implicit conversion you can tell it exactly how the fuck you want it to handle the conversion.

FTFY