Bad programming practices encouraged.... namely VB!

[Bob Butler]

"Patrick Troughton" <Patrick@Troughton.com> wrote in message
news:3ad9105b$1@news.devx.com...
>
> "Patrick Troughton" <Patrick@Troughton.com> wrote:
> >And keep in mind that some or at least many VB6 programs will never be
>
> Meant to say, "many or at least some"

Didn't even notice that. I like it though<g>

[Jonny]

K & Z

> > I take it as my honor to count Jonny as a friend, so yeah it figures.
>
> <aol>Me too!</aol>

Enough already guys, I am welling up here [sniff, wipe]

Jonny

PS. The honor is fully reciprocated.

[Larry Serflaten]

"Bob Butler" <butlerbob@earthlink.net> wrote

> On-going ease of maintenance is the gain I see from keeping -1. I still see
> no benefit at all to going to +1 for the Cxxx functions.

What about CType?

MyVal = CType(boolFlag, Integer)

Its new, so should it use the new (+1) conventions? Then, for the beginner,
how are you going to explain CInt returning -1 and CType returning +1

Mixed mode seems like its going to be a nightmare. While I see it would cause
problems, I still would rather favor using one value for True, consistantly....

LFS

[Jonny]

Kunle

> Some people (who believe in explicit programming) use
CInt(bBooelanVariable)
> to get the value of true that may then be written to (and read from)
files,
> comms sockets or other external stream. The change might break these
cases.

FWIW. I have a vague, possibly 'recovered', memory of the VB2 or 3 help
files saying something like: "In VB the integer value of True is 'Not
Zero'" All my programming life I have never assumed True to be any
actual value since only False could be defined, IOW True has always been
a set of integers. Seems like MS was hedging their bets back then.

> If you were trying to get web-forms working Jonny, wouldn't the MS
newsgroup
> for ASP.NET be a better place to go?
> news:microsoft.public.dotnet.framework.aspnet

Good idea, thanks for the tip.

Jonny

[Bob Butler]

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:3ad9fd97@news.devx.com...
>
> "Bob Butler" <butlerbob@earthlink.net> wrote
>
> > On-going ease of maintenance is the gain I see from keeping -1. I still
see
> > no benefit at all to going to +1 for the Cxxx functions.
>
> What about CType?
>
> MyVal = CType(boolFlag, Integer)
>
> Its new, so should it use the new (+1) conventions? Then, for the
beginner,
> how are you going to explain CInt returning -1 and CType returning +1

CType I could see going either way and I think a good argument could be made
for it being new so +1 is appropriate but also that it is semantically very
close to CInt/CLng/etc and should therefore be consistent with that and
return -1.

Since there is no VB6 code that uses CType I don't care which way it goes.
Any code you see that uses CType is not ambiguous - whatever it is defined
to do is the bottom line.

> Mixed mode seems like its going to be a nightmare. While I see it would
cause
> problems, I still would rather favor using one value for True,
consistantly....

I guess I see problems with mixed mode but I see changing CInt/etc as the
nightmare. I do not think making the VB conversion functions different than
the dotnet functions as "good", just as the best solution given the whole
situation. Unless MS decides to make Boolean convert to -1 in dotnet (and
push this problem off to the C side) I see the current setup as the most
reasonable approach.

[Kunle Odutola]

Hi Jonny,



"Jonny" <jonny@joyofvb.com> wrote in message news:3ada195f@news.devx.com...
> Kunle
>
> > Some people (who believe in explicit programming) use
> CInt(bBooelanVariable)
> > to get the value of true that may then be written to (and read from)
> files,
> > comms sockets or other external stream. The change might break these
> cases.
>
> FWIW. I have a vague, possibly 'recovered', memory of the VB2 or 3 help
> files saying something like: "In VB the integer value of True is 'Not
> Zero'" All my programming life I have never assumed True to be any
> actual value since only False could be defined, IOW True has always been
> a set of integers. Seems like MS was hedging their bets back then.

Logically, I don't think of True as having a particular value either Jonny.
The use of CInt is a different kettle of fish though.
When applied to boolean values, I see it more as a map to an arbitary but
consistent integer value. It is an explicit conversion to Integer and not
the value of True if you see what I mean.

Kunle

(Hey some way cool stuff on your site!)

[Vlad Ivanov]

"Kunle Odutola" <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:

>Logically, I don't think of True as having a particular value either Jonny.
>The use of CInt is a different kettle of fish though.
>When applied to boolean values, I see it more as a map to an arbitary but
>consistent integer value. It is an explicit conversion to Integer and not
>the value of True if you see what I mean.
>

Kundle,

This is the clearest and simplest post on the subject i have read here. So
true. I wish the people who critisize concession to classic vb just understood
such simple explanation as you provided. This is pretty much what many are
saying (Dan comes to mind) but simpler. And doesn't hurt VB.Net and interoperability
at all. As far as i am concerned - this post should close the issue. At least
for one of those 3 changes.

CInt returns 0 for false and -1 for true when passed expression that results
in a boolean value as a parameter.

:-)

[Patrick Troughton]

"Bob Butler" <butlerbob@earthlink.net> wrote:
>
>"Patrick Troughton" <Patrick@Troughton.com> wrote in message
>news:3ad8f3f1$1@news.devx.com...
><cut>
>> But in the real
>> world, there are tons of VB programmers who don't even bother to use
>Option
>> Explicit and you think they'll appreciate the difference between Cint
and
>> ToInt32?
>
>If you work in a team environment and do not use Option Explicit and have
>team members that do not understand the difference between CInt and
>Convert.ToInt32 then you have bigger problems than the value of True.

So you're saying two wrongs make a right? You're talking to the wrong person
if you expect me to buy that argument.

>> Even if they do, what happens when one person's or shop's standard
>> is to use Cint and another's is to use ToInt32?
>
>They do different things.

Yep, one converts a value to a 4 byte signed integer and the other converts
a value to a 4 byte signed integer. Yep, makes perfect sense and is highly
intuitive too! Who says BASIC isn't simple?

>If some shop did standardize on one or the other for some reason, so what?

They may not interop well, or even at all. If we do it right in the first
place, this won't even be a problem in the first place.

/Pat

[Bob Butler]

"Patrick Troughton" <Patrick@Troughton.com> wrote in message
news:3adb0630$1@news.devx.com...
>
<cut>
> >If you work in a team environment and do not use Option Explicit and have
> >team members that do not understand the difference between CInt and
> >Convert.ToInt32 then you have bigger problems than the value of True.
>
> So you're saying two wrongs make a right? You're talking to the wrong
person
> if you expect me to buy that argument.

That's not even close to what I said. I'm saying that CInt is a legacy VB
function that works consistently with the way it has in previous VB
versions. When you see a line of code that reads "x=Cint(a>b)" you know
immediatley what it does without having to track down what version of VB it
was written for. Similarly when you see "x=Convert.ToInt32(a>b)" you also
know what it does. The fact that the results differ is totally irrelevent
as far as I'm concerned just like the Fix() and Int() functions can return
different results because they have different purposes.

> >> Even if they do, what happens when one person's or shop's standard
> >> is to use Cint and another's is to use ToInt32?
> >
> >They do different things.
>
> Yep, one converts a value to a 4 byte signed integer and the other
converts
> a value to a 4 byte signed integer. Yep, makes perfect sense and is highly
> intuitive too! Who says BASIC isn't simple?

Many functions return a 4-byte signed integer but given the same input I
don't expect the same output from them all.
Try not thinking of it as converting so much as translating the value into
another system. CInt translates True in the classic VB context of -1 while
Convert translates True to the dotnet context of +1.

For that matter, CStr translates the boolean True to the English text
"True" - isn't it inconsistent that Convert.ToInt32(True) returns +1 but
CStr(True) returns "True"? Shouldn't it return "+1" instead?

> >If some shop did standardize on one or the other for some reason, so
what?
>
> They may not interop well, or even at all. If we do it right in the first
> place, this won't even be a problem in the first place.

What does interop have to do with it? If your claim is that newbies can
misuse the functions then you are right - newbies, and even veterans, can
misuse lots of things in the language. The distinction between how classic
VB handled this and how VB.Net handles it is useful, IMO, and the potential
problems with it are phantoms.

At this point I suggest we wait for Beta 2 and get a chance to see exactly
how the various functions work and how components interact with each other.
That may illustrate problems that I simply do not see happening and it may
ease fears that you have about problems that you do expect.

[Rob Teixeira]

I've been thinking a lot about this (though not as much as some other more
important issues), and I've come to the conclusion that it's as good a compromise
as anyone is going to get. Bob is right. It's a matter of perspective in
a sense. If you look at the conversion functions, when using a boolean for
input:

ToString() = convert to string representation
ToInt32() = convert to CLR integer representation (+1)
CInt() = convert to VB6 integer representation (-1)

It's easy enough to explain to the genericly labelled "newbie". Anyone who
can't get that simple explanation shouldn't be programming. The "Find" dialog
is a quick way to see if CInt exists in any code.
Of course, abrubptly after giving the aforementioned explanation to the hypothetical
team of newbies, I'll follow up with...

"That being the case, you are NOT converting VB6 code here. So each CInt
I see in your code is gonna cost you an appendage. That 21st CInt is a doosey."

As you can see, I still don't condone mixing the two.
I think that the number of predicted integer-boolean mix-up code problems
in VB.NET is most likely over-exagerated, which is not to say it won't happen
at all. When it does happen, it can be dealt with rather easily.

-Rob

"Bob Butler" <butlerbob@earthlink.net> wrote:
>
>
>That's not even close to what I said. I'm saying that CInt is a legacy
VB
>function that works consistently with the way it has in previous VB
>versions. When you see a line of code that reads "x=Cint(a>b)" you know
>immediatley what it does without having to track down what version of VB
it
>was written for. Similarly when you see "x=Convert.ToInt32(a>b)" you also
>know what it does. The fact that the results differ is totally irrelevent
>as far as I'm concerned just like the Fix() and Int() functions can return
>different results because they have different purposes.
>

[Kunle Odutola]

"Mark Hurd" <markhurd@ozemail.com.au> wrote in message
news:3ad949de@news.devx.com...
> "Kunle Odutola okocha.freeserve.co.uk>" <kunle.odutola@<REMOVETHIS> wrote
in
> message news:3ad83861$1@news.devx.com...
> >
> > "Dan Barclay" <Dan@MVPs.org> wrote in message
> > news:joi4dt018bh9hjttivpm17iqlgklib2j8n@4ax.com...
> <snip>
> > > If MyValue% And MyMask% And A>B Then ' masked bits with a switch
> >
> > Learn to code properly please (don't just mix logical and bitwise
> expression
> > just because you can):
>
> This is some sort of reverse arrogance. I understand the code as written.
I
> understand the concept of writing code for maintenance programmers, but I
> expect then to understand the language, and, of course, the code above
would
> have a comment explaining what it is for. eg:

Two issues here Mark.
1) A computer application's source code is a set of instructions to tell a
computer how to do something. For any given task there are a great many ways
to write the instructions (source code) and the computer wouldn't care less.
Now, human have to read and maintain the source code and many would argue
(myself included) that it is vitally important to write source code that is
easy understand and extend or modify.

2) The lack of distinct logical and bitwise operators is a flaw of the
classic VB language. The effect this can have (as shown by the code I
commented on) is to support/encourage bad programming habits. Such a simple
fragment of code should be written to be self-explanatory. It should not
need comments to explain what it is.

Compare this code sample to your code (or Dan's original snippet) that
requires a comment IMO:

bShowTerrainDetail = ((bmapCurrentDisplayOptions% And
bmaskShowTerrainDetail%) <> 0)
If (CurrentDetailLevel < TerrainDetailLimit) Then
If (bShowTerrainDetail) Then
' your code goes here
' (explicit programming to the rescue)
Else
' blah..blah...
End If
End If

> ' If user selected to show details and the current level is deeper than
> the detail limit,
> If DisplayOptions% And ShowDetailsMask% And Level > DetailLevel Then
>

>
> Firstly, I hope this is a combination of a typo and lack of respect to
order
> of evaluation (which is fair enough) rather than attempting to implement a
> short-circuit replacement.
>
> Secondly, surely the only change needed is this:
>
> If (MyValue% And MyMask% <> 0) And (A > B) Then ' masked bits with
a
> switch

This is better, although it still requires better [self-documenting]
variable names. This revision doesn't mix bitwise and boolean expressions.

>
> and this is what I'd write in new code, as a concession to the maintenance
worry.

Maintenance is usually the longest, costliest and, most important
development activity/phase for most applicatons. You may be itching to write
new code but if your code is written without consideration for it's
maintenance then you have failed.

> Which VB6 features are hacks, which are misused features? Which of your
> answers are in your opinion?

Many but this thread touches on the logical/bitwise operator flaw.
And that is also a misused feature as the code sample that mixed bitwise and
logical expression proves.

> Code that is hard to maintain is not bad code, it is just bad code for the
> situation. Admittedly most code needs to cater for maintenance, but if
that
> is a goal in itself there is lots of work to do...

If we are talking about code written by/for a commercial entity then it is
bad code as it will cost more money to fix/maintain/modify than if it had
been written properly in the first instance.

> > VB: To infinity or the dump...
>
> Don't agree with your sig in its original context, but I still smirk :-))
> Good one.

<g>

Kunle

[Gregor R. Peisker]

Hi Kunle,

> 2) The lack of distinct logical and bitwise operators is a flaw of the
> classic VB language. The effect this can have (as shown by the code I
> commented on) is to support/encourage bad programming habits. Such a
simple
> fragment of code should be written to be self-explanatory. It should not
> need comments to explain what it is.

Yes, self-documenting code. It is beyond me why some people want to throw
away code clarity that we could so readily have.

I also have a hunch that the "You should always have Option Strict On"
argument is employed by some people as a cheap way to argue their way out
this issue.

Regards,
Gregor

[Gregor R. Peisker]

Hi a29379,

> "Reasonable people adapt to the world.
> Unreasonable people persist in trying to adapt the
> world to themselves. Therefore, all progress
> depends on unreasonable people."
> --George Bernard Shaw

Yes, a great quote. But in which way shall we interpret it here?

Thanks,
Gregor

[Dan Barclay]

On Sat, 14 Apr 2001 12:50:12 +0100, "Kunle Odutola"
<kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:

<snip>
>>
>> The *intrinsic* value of true is the issue. That is, the result of a
>> comparison: "A>B" must be 0 or -1 for existing *perfectly proper*
>> code to work.
>
>Wrong Dan. Wrong big time.

Nope, this statement is correct. That is, in the context of the MS
Basic language it is correct.

>
>PROBLEM: Lack of logical operators in VB.
>CONSEQUENCE: Programmers had to use the bitwise operators as logical
>operators.
>SOLUTION: Introduce proper logical operators (separate from bitwise
>operators) and provide a way to support code migration (Upgrade Wizard)
>F***UP: Somebody felt it would be easier to just propagate a glaring
>failure/omission of classic VB (lack of logical operators) rather than fix
>it.

Agreed. I have no problem with extensions of the language, including
adding "proper logical operators". I'm not sure it's worth the effort
since use of Boolean typed variables will give the same results, but
it is certainly reasonable.

>VISION: Recognizing the difficulties these fundamental issue presents, I
>suggest that there the best way is to support both both only one at a time.
>The programmer gets to choose which semantics to use by specifying and
>Option VB6Compatibility statement or similar...

I don't agree with using an Option statement. Either the language is
a language (maximizing forward compatibility) or it is not.

>
>> If MyValue% And MyMask% And A>B Then ' masked bits with a switch
>
>Learn to code properly please (don't just mix logical and bitwise expression
>just because you can):

This is a perfectly proper expression in Basic. What's more, from the
*language* standpoint, it's entirely bitwise (doesn't mix logical and
bitwise). The compiler can optimize it in any way it wants.

> If (A < B) Then
> If (MyValue% And MyMask%) Then
> ' your code goes here
> ' (explicit programming to the rescue)
> End If
> End If

Yes, that works but it isn't necessary. Your mileage may vary.

>> Learn more about the issue before you start spouting off and you won't
>> look so much the idiot. Start here if you'd like:
>>
>> http://www.mvps.org/vb/tips/truth.htm
>>
>> >I think any changes on the VB side to come more into align with the rest
>> >of the programming community should be welcome.
>>
>> Actually, I think we need to make some more changes with these
>> objectives in mind. Both VB and MSIL have "And" as the bitwise
>> operator... perhaps C# needs to be in compliance?
>
>Now you propose that VB must be in compliance with MSIL. That is reaching
>Dan, damned near fully extended and still reaching...

No, I actually don't (as you know). However, for those who think
consistency between languages is critical it only makes sense.

>The removal of logically named, distinct, logical operators (from Beta 1) to
>be replaced with historical VB hacks and a set of sorryass, weirdly names,
>pretenders is an example of changes that VB can do without.

If you're calling "And/Or/Not/Xor" sorryass, wierdly names, pretenders
I think you're off base. If you're talking about "AndAlso/OrElse" I'm
not sure I could agree more.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Mike Mitchell]

On Sat, 14 Apr 2001 20:59:32 +0100, "Kunle Odutola"
<kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:

>Many of us want MS to remove those hoops. Rather than continue to seek new
>ways to jump through them...

But while they were hoops, we knew where the other side was. Now
Microsoft is changing the hoops into tunnels which twist and turn so
that we do not know how long the journey will be or where we will end
up.

Give me the hoops any day!

MM