Not as 'explicit' as I thought --- What am I missing

  • Thread starter Thread starter Dale Atkin
  • Start date Start date
D

Dale Atkin

I've been a big fan of explicit variable declaration ever since many years
ago when I spent nearly a whole day trying to track down a bug, that was the
result of a simple 'typo'. Ever since, I've made sure "Option Explicit" was
on in every program I write, and I've never looked back.

I've noticed however that in certain circumstances, the compiler doesn't
seem to mind inferring the data type of some variables.

For example, I would have expected that the following code would generate an
error:

Private Function DoSomething() As String
For i = 0 To 10000

Next
Return 0
End Function

But it doesn't. It seems that the For loop is somehow an exception to the
'explicit' variable declaration rule, and I'm not sure why, or what other
situations this same 'exception' might apply in, and its making me a bit
nervous.

Dale
 
Dale said:
I've been a big fan of explicit variable declaration ever since many
years ago when I spent nearly a whole day trying to track down a bug,
that was the result of a simple 'typo'. Ever since, I've made sure
"Option Explicit" was on in every program I write, and I've never
looked back.
I've noticed however that in certain circumstances, the compiler
doesn't seem to mind inferring the data type of some variables.

For example, I would have expected that the following code would
generate an error:

Private Function DoSomething() As String
For i = 0 To 10000

Next
Return 0
End Function

But it doesn't. It seems that the For loop is somehow an exception
to the 'explicit' variable declaration rule, and I'm not sure why, or
what other situations this same 'exception' might apply in, and its
making me a bit nervous.


1. With a for loop you can write:

for i as integer = 0 to 10000

This has nothing to do with Option Explicit, it's just a simplified way to
declare the loop variable at block scope.

2. With Option Infer On, you can write

dim i = 17

which is equal to

dim i as integer = 17


3. If you put #1 and #2 together you can write

For i = 0 To 10000

which explicitly declares variable i. Therefore it's not a violation of the
Option Strict rule. It's just it's type that is inferred from the start and
end values.



Armin
 
I've been a big fan of explicit variable declaration ever since many years
ago when I spent nearly a whole day trying to track down a bug, that was the
result of a simple 'typo'. Ever since, I've made sure "Option Explicit" was
on in every program I write, and I've never looked back.

I've noticed however that in certain circumstances, the compiler doesn't
seem to mind inferring the data type of some variables.

For example, I would have expected that the following code would generate an
error:

Private Function DoSomething() As String
For i = 0 To 10000

Next
Return 0
End Function

But it doesn't. It seems that the For loop is somehow an exception to the
'explicit' variable declaration rule, and I'm not sure why, or what other
situations this same 'exception' might apply in, and its making me a bit
nervous.

Dale

If your using VB2008, try:

Option Infer Off
 
1. With a for loop you can write:

for i as integer = 0 to 10000

This has nothing to do with Option Explicit, it's just a simplified way to
declare the loop variable at block scope.

2. With Option Infer On, you can write

dim i = 17

which is equal to

dim i as integer = 17


3. If you put #1 and #2 together you can write

For i = 0 To 10000

which explicitly declares variable i. Therefore it's not a violation of
the Option Strict rule. It's just it's type that is inferred from the
start and end values.

That makes a lot of sense actually. Thanks for the detailed explanation. I'd
noticed some of the 'option infer' stuff, but didn't tie it together with
how this would play out within a for loop.

I think I'll probably turn off Option Infer, and see if I like/dislike this
feature. If it starts to bug me, I'll turn it back on.

Dale
 
Dale Atkin said:
That makes a lot of sense actually. Thanks for the detailed explanation.
I'd noticed some of the 'option infer' stuff, but didn't tie it together
with how this would play out within a for loop.

I think I'll probably turn off Option Infer, and see if I like/dislike
this feature. If it starts to bug me, I'll turn it back on.

Dale

Option Infer is used quite a bit with Linq. I create classes for DB access
using Linq and those classes have Infer On, all other classes have Infer
Off. You can set that on a project basis and just set to On for those
classes that need it.

LS
 
Back
Top