CodeSOD: Extra Strict

One of the advantages of a strongly typed language is that many kinds of errors can be caught at compile time. Without even running the code, you know you've made a mistake. This adds a layer of formality to your programs, which has the disadvantage of making it harder for a novice programmer to get started.

At least, that's my understanding of why every language that's designed to be "easy to use" defaults to being loosely typed. The result is that it's easy to get started, but then you inevitably end up asking yourself wat?

Visual Basic was one of those languages. It wanted to avoid spitting out errors at compile time, because that made it "easy" to get started. This meant, for example, that in old versions of Visual Basic, you didn't need to declare your variables- they were declared on use, a feature that persists into languages like Python today. Also, in older versions, you didn't need to declare variables as having a type, they could just hold anything. And even if you declared a type, the compiler would "do its best" to stuff one type into another, much like JavaScript does today.

Microsoft recognized that this would be a problem if a large team was working on a Visual Basic project. And large teams and large Visual Basic projects are a thing that sadly happened. So they added features to the language which let you control how strict it would be. Adding Option Explicit to a file would mean that variables needed to be declared before use. Option Strict would enforce strict type checking, and preventing surprising implicit casts.

One of the big changes in VB.Net was the defaults for those changed- Option Explicit defaulted to being on, and you needed to specify Option Explicit Off to get the old behavior. Option Strict remained off by default, though, so many teams enabled it. In .NET, it was even more important, since while VB.Net might let you play loose with types at compile time, the compiled MSIL output didn't.

Which brings us to Russell F's code. While the team's coding standards do recommend that Option Strict be enabled, one developer hasn't quite adapted to that reality. Which is why pretty much any code that interacts with form fields looks like this:

Public i64Part2 As Int64'later...i64Part2 = Format(Convert.ToInt64(txtIBM2.Text), "00000")

txtIBM2 is, as you might guess from the Hungarian tag, a text box. So we need to convert that to a number, hence the Convert.ToInt64. So far so good.

Then, perplexingly, we Format the number back into a string that is 5 characters long. Then we let an implicit cast turn the string back into a number, because i64Part2 is an Int64. So that's a string converted explicitly into a number, formatted into a string and then implicitly converted back to a number.

The conversion back to a number undoes whatever was accomplished by the formatting. Worse, the format give you a false sense of security- the format string only supports 5 digits, but what happens if you pass a 6 digit number in? Nothing: the Format method won't truncate, so your six digit number comes out as six digits.

Maybe the "easy to use" languages are onto something. Types do seem hard.

[Advertisement] ProGet can centralize your organization's software applications and components to provide uniform access to developers and servers. Check it out!