Bad programming practices encouraged.... namely VB!

[Kathleen Dollard-Joeris]

Kunle,

Trying to best clarify this with the egg on my face sticking my eyes shut. I
was absolutely wrong when I said the following.

> > You want a compatibility switch. It is the Imports on the VB6
> compatibility
> > namespace. CInt _resides in a namespace with the word "Compatibility" in
> its
> > name! If you don't want VB6 compatibility- _don't use this
namespace!!!!!_

CInt is handled by the compiler and is not in a namespace. Man did I blow
it.

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Kunle Odutola]

"Kathleen Dollard-Joeris" <kjoeris@noemailplease.com> wrote in message
news:3ad88ea2@news.devx.com...
> Kunle,
>
> Trying to best clarify this with the egg on my face sticking my eyes shut.
I
> was absolutely wrong when I said the following.

I spotted it Kathleen. Thought this detail might be changed anyways in which
case you would be right and any comment I made would then be wrong?

Kunle

> > > You want a compatibility switch. It is the Imports on the VB6
> > compatibility

<SNIP>

[Rick Barnett]

"Patrick Troughton" <Patrick@Troughton.com> wrote in message
news:3ad8771e$1@news.devx.com...
>
> "Kathleen Dollard-Joeris" <kjoeris@noemailplease.com> wrote:
> >
> >I am tired of this debate.
>
> That's too bad because you'll be hearing this debate until these
inconsistancies
> are fixed. And if they're not, make sure you don't spend anytime in the VB
> newsgroups because you'll be explaining why VB.NET thinks 1 is equal to -1
> for the next 5 to 10 years. As the saying goes, be careful of what you wish
> for because you might just get it.

I agree. I think Microsoft is being just plain stupid carrying forward an
arbitrary constant for True just to be compatible with the past. Let's begin the
campaign to have Microsoft fix the .NET framework by making True = Not False
like it should be.

[Mike Mitchell]

On Sat, 14 Apr 2001 11:21:38 +0930, "Mark Hurd"
<markhurd@ozemail.com.au> wrote:

>It is clear from my experience that there are two major groups of
>professional VB programmers. There are those who use it as a glue to join
>components including database access. And those who use it as an application
>development language.

I don't see how the addition of a database affects anything. With ADO
I can get a recordset out of a dead horse if I need to. Okay, not
quite a dead horse, but most everything else, including a bog-standard
text file (with a schema.ini). I have colleagues who use SQL Server,
xBase (yes, Karl!), Access, and AS/400/DB2. I have written numerous
apps that don't use a database, but store data in INI-like files - all
the readability of XML without the tagging bloat. And I have also
written apps which use a properly designed, normalised, relational
database. The beauty of VB is that it *is* so amenable to so many
different kinds of application. I mean, you'd consider playing around
with UDP datagrams fairly low-level, wouldn't you? It's not something
many VB coders will have written code for, but I have and again, VB
lets you do that, too.

>
>The former is a much larger group, especially if you include VBA, which is
>almost by definition included in this group.

I agree that VB's forte is providing a user-friendly, flexible,
reliable front-end to databases. When you've seen the green screens so
loved by some of the mainframe ERP providers and the kind of work
they're getting into with screen scraping, then VB just looks too easy
- which is why it has been so successful.

>
>I am not saying a database front-end is not a complete application, but the
>two uses are fairly clear cut even within the one project.
>
>There is probably now a third group, component writers and class-only
>stuff -- the middle tier of a three-tiered system.
>
>One of the best distinctions between the groups is whether they have ever
>used a Declare declaration, or because of the amount of sample code out
>there, whether they have ever looked at a C declaration and converted it
>into a Declare statement.

Although I class myself as an application developer, I make heavy use
of the Win32 API and have rarely been unable to achieve through its
use what I set out to do. With books such as Dan Appleman's, plus
many, useful articles in VBPJ and elsewhere, I have been able to make
VB jump through hoops without a murmur. That's why C++ programmers
hate us so. They just can't stand to see a VB coder produce a solution
in five minutes that would them the whole day. I've also written my
own C DLLs (not C++ nota bene) for calling from VB apps (and earlier,
BASIC 7 apps), so probably I am more experienced than many application
developers. (Shrinking violet, moi?!!)

>
>My first experience with VB, was with a tax accounting application that did
>not use a database to store its data. We wrote to binary files and found it
>very funny when customers asked how many company files could fit on a floppy
>disk. They had seen our competition which stored full databases, and so
>could only have a few on a single floppy.
>
>We had to go off and check that the answer was dozens or hundreds.

This is exactly how I use to think. Flat files were great. Sometimes
they are, but once you've been seduced by the relational aspects of a
well-designed database, flat files can look a tad dated. Nevertheless,
flat files are blindingly quick, especially on modern supercomputers
(like the ones we've all got on our desks), and I am certainly not
going to say, unlike some people I'll not bother to mention here, that
you always have to move to the next big idea. What I do say is, if it
works for you, there's no need to reinvent the wheel and you can save
your employer a bundle, which might actually mean a bonus for you, if
it means he hasn't spent it on pointless upgrades.

>
>This application also implemented DDE for linking into 1-2-3 and Excel,
>copying RTF to the clipboard using the API, and generally had the look and
>feel of a complete Microsoft application. (Yes, without the bugs.)
>
>This development actually caused me problems career-wise: I was there (it
>was Coopers & Lybrand) for 3.5 years and we never looked at databases. So I
>was a VB "expert" except for databases. I had to explain to a number of
>database-based potential employers that I use VB like C, as an application
>development environment, not like a database macro language.

In case others reading this should be deterred from learning about
databases, let me say that it is not difficult at all, given the
amount of easily accessible tools available. For example, I hardly
ever bother to write a complicated SQL query. I'm lazy (like all good
programmers) and believe in getting the computer to work for *me*, not
the other way round. So I'll use the QBE wizard in Access, for
example, to quickly knock up a query template for me. There really are
only a few, basic facts one needs to know in setting up a relational
database (autonumbered or identity ID field in ALL tables;
normalisation; referential integrity), and I reckon that any VB user
with some experience of coding could be working with data via ADO in a
fairly short time. Providing Microsoft don't rename it next week or
revamp it completely. (What d'you mean, they have already?)

>
>I did find work where they were transforming a mainframe app to Windows and
>the web, so I happened to be able to use my existing skills and the database
>work going on at the same time caused me to understand that side too.
>
>So back to my point: VB has a feature that is you can easily get a lot done
>without understanding the complete language, or event the constructs you are
>using. That is both a good thing and a bad thing, that's why I call it a
>feature :-)

I don't recognise the 'bad thing' part, I'm afraid. Everything about
the ease of use, its accessibility to vast numbers of ordinary users,
its flexibility for so many different kinds of application, and the
sheer satisfaction one gets from using it, means for me that every
fact of classic VB is good, though some areas (notably the help
system, which is utter crap) could be improved upon.

In my book, the words VB and bad don't come in the same sentence.
Except that one.

MM

[Mike Mitchell]

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

>PROBLEM: Lack of logical operators in VB.

Whoa, stop right there! In my "Microsoft Visual Basic Programmer's
Guide it says, under "Visual Basic Operators":

"Visual Basic supports a rich set of arithmetic, relational, and
logical operators...." and then proceds to list Not, And, Or, Xor,
Eqv, and Imp in the category "Logical (bit-wise)".

So what problem are you all desperately trying to find a solution for?
Is this whole argument merely to justify short-circuiting syntax? Even
though short-circuiting, as has been shown, could always be done
anyway? If you remove the short-circuiting argument, what argument is
left for changing And etc?

MM

[Gregor R. Peisker]

Hey, it's only a Beta!

Gregor


> Darn,
>
> What can I say?
>
> I was wrong. You can not remove this functionality.
>
> I thought it was in a separate library and thus explicitly added. I was
> wrong.
>
> There is no reason to believe there are any plans for different behavior
in
> beta2 or in the future.
>
> Always like to learn something and be corrected when I am wrong. Always
hate
> to do it in public. Ah well.
>
> --
> Kathleen
> (MS-MVP)
> Reply in the newsgroup so everyone can benefit
> --

[Kunle Odutola]

> Although I class myself as an application developer, I make heavy use
> of the Win32 API and have rarely been unable to achieve through its
> use what I set out to do. With books such as Dan Appleman's, plus
> many, useful articles in VBPJ and elsewhere, I have been able to make
> VB jump through hoops without a murmur.

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

Kunle

VB: To infinity or the dump...

[Kunle Odutola]

"Mike Mitchell" <kylix_is@hotmail.com> wrote in message
news:3ad8a3ae.31464078@news.devx.com...
> On Sat, 14 Apr 2001 12:50:12 +0100, "Kunle Odutola"
> <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:
>
> >PROBLEM: Lack of logical operators in VB.
>
> Whoa, stop right there! In my "Microsoft Visual Basic Programmer's
> Guide it says, under "Visual Basic Operators":
>
> "Visual Basic supports a rich set of arithmetic, relational, and
> logical operators...." and then proceds to list Not, And, Or, Xor,
> Eqv, and Imp in the category "Logical (bit-wise)".
>
> So what problem are you all desperately trying to find a solution for?
> Is this whole argument merely to justify short-circuiting syntax? Even
> though short-circuiting, as has been shown, could always be done
> anyway? If you remove the short-circuiting argument, what argument is
> left for changing And etc?

Mike, please search through the countless discussions of the changes for the
lowdown on VB's bitwise operators...and don't always believe what you read
in the manual.

Kunle

VB: To infinity or the dump...

[Zane Thomas]

On 14 Apr 2001 09:13:18 -0700, "Patrick Troughton" <Patrick@Troughton.com>
wrote:

>That's too bad because you'll be hearing this debate until these inconsistancies
>are fixed.

Wrong - two years from now most people will be embarassed that they wasted
so much time going over the same points ad nauseum.


---
Ice Z - Straight Outta Redmond

[Bob Butler]

"Patrick Troughton" <Patrick@Troughton.com> wrote in message
news:3ad869c4$1@news.devx.com...
>
> And rollback to -1 can cause a problems with all subsequent development!
You're
> sacrificing the long-term for the short term, which is never a good trade
> off....

If, in future development, you find that you want to convert Booleans to
Integers and back using +1 you use Convert.ToInt32 instead of the legacy
CInt function or you use Abs() or some other method to ensure that the
integer representation of True is what you want it to be. If you want to
campaign for marking the Cxxx functions as obsolete so that people have to
deal with warnings when they use them and know that they will be removed in
VB.Net 2.0 (assuming that ever exists) then I'd see that as a reasonable
path towards getting rid of the perceived discrepancy. Simply declaring that
+1 is a "better" value than -1 and that code that has been working fine for
years is wrong or poor quality strikes me as highly arrogant.

[Patrick Troughton]

"Bob Butler" <butlerbob@earthlink.net> wrote:
>
>"Patrick Troughton" <Patrick@Troughton.com> wrote in message
>news:3ad869c4$1@news.devx.com...
>
>If, in future development, you find that you want to convert Booleans to
>Integers and back using +1 you use Convert.ToInt32 instead of the legacy
>CInt function or you use Abs() or some other method to ensure that the
>integer representation of True is what you want it to be.

I'm not necessarily talking about myself, Bob. Maybe you work alone, but
many of us work in teams or inherit code from other people or even download
it from the internet. In a perfect world, everyone would follow the exact
same coding standards and everything would be honkey-dorey. 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? 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?

.NET will probably be Microsoft's preferred programming platform for the
next 5-10 years. Will -1 make things a little easier to port from VB6 to
VB.NET? Yes. I don't deny that.

But 3-5 years from now, will that really matter? Probably not. Changing VB's
True from -1 to 1 is a one time conversion problem. But once it's done, it's
done. An inconsistant value for True is a long-term problem we'll be dealing
with as long as .NET exists. I would much rather get it over with now rather
than drag it out. In short, we're sacrificing the long term for short-term
gain.

And keep in mind that some or at least many VB6 programs will never be ported
to .NET. They'll be rewritten. I can't predict the future, but if this turns
out to be the case, then we've sacrificed the long-term term for no short
term gain. In which case, we've gained nothing for the trade-off.

> Simply declaring that
>+1 is a "better" value than -1 and that code that has been working fine
for
>years is wrong or poor quality strikes me as highly arrogant.

Bob, this has nothing to do with whether it's 1 or -1, just as long as it's
consistant. I honestly don't care what True is just as long as it's the same
across .NET and within VB.NET programs. And right now it is NOT consistant.

/Pat

[Patrick Troughton]

"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"

/Pat

[Mark Hurd]

"Mike Mitchell" <kylix_is@hotmail.com> wrote in message
news:3ad8387e.4020644@news.devx.com...
> On Sat, 14 Apr 2001 11:21:38 +0930, "Mark Hurd"
> <markhurd@ozemail.com.au> wrote:
<snip us comparing war stories :-) >
> >So back to my point: VB has a feature that is you can easily get a lot
done
> >without understanding the complete language, or event the constructs you
are
> >using. That is both a good thing and a bad thing, that's why I call it a
> >feature :-)
>
> I don't recognise the 'bad thing' part, I'm afraid. Everything about
> the ease of use, its accessibility to vast numbers of ordinary users,
> its flexibility for so many different kinds of application, and the
> sheer satisfaction one gets from using it, means for me that every
> fact of classic VB is good, though some areas (notably the help
> system, which is utter crap) could be improved upon.

The bad thing is if you have to maintain existing code that uses the
features you don't know about. OK, so you have to learn about using database
objects if you didn't already know about them. That is a fairly clear
situation: you'll probably have to admit to your boss that you have to read
up and do some experimenting.

But if you don't really know how And and Or work (that is, you think logical
whereas they are actually bitwise), you'll easily misunderstand code that
uses their bitwise features. I see that as a bad thing. In C, you may not be
sure what the difference between ++i and i++ is, but it is unlikely that
you'll just assume something. (There is probably a better example.)

As far as "the help system" is concerned: the metadata (using the now coined
term) attached to VB code and components is very good; that context (and
type) sensitive help works is good; the content was OK but got worse; and,
HTML Help is somewhat like VB.NET -- good intentions, even has some good
features, but hopeless compared to the technology it is replacing. (VB.NET
has great features and is not quite better than the technology it is
replacing -- because it shouldn't be marketed as a replacement. As a new
language it is fantastic: what is the wishlist of features to add to it that
don't exist in other *released* languages? A short-circuited Iif, multiple
inheritence, ... fairly minor or quite major changes.)

>
> In my book, the words VB and bad don't come in the same sentence.
> Except that one.
>
> MM

In general, I find discussing VB.NET versus VB to be hard to keep to just
one issue. As a package VB.NET is great. I find it surprising that so many
see C# as an exclusive alternative. From the discussion and examples I've
seen so far, C# is not needed for a VB programmer, just VB.NET and MC to
produce exported functions in DLLs.

The only argument that has some merit is "VB.NET is so different to VB, then
I might as well learn C# as my .NET language", but I hope Microsoft will
invest more into VB.NET promoting it for tasks that were best done in VB
before.

It seems that C# is about as powerful as VB and about good at RAD, and has
the same forms package, etc. There are only a few differentiators. This is
where I think that it makes sense for VB.NET to be *more* BASIC-like rather
than less -- every BASIC concept it drops makes it more like C# and thus
more redundant.

Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)

[Mark Hurd]

"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:

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

> If (A < B) Then
> If (MyValue% And MyMask%) 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

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

<snip>
>
> I agree VB needs to still retain the flavour of VB (whatever that is) but
an
> hack is a hack and an omission is an omission. No point in saying
> *everything* that VB had must be protected just because it has always been
> there or somebosy has used (or more commonly) misused it!

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

If it was documented then the use was valid.

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...

>
> Kunle
>
> VB: To infinity or the dump...

Don't agree with your sig in its original context, but I still smirk :-))
Good one.

Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)

[Bob Butler]

"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.

> 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. A standard on one or the other makes no sense to
me since (a) it's something that good coding practices will rarely, if ever,
do and (b) if you do need to do it then you choose the method that gives the
correct result for the specific situation. Asking whether a standard of
CInt or Convert.ToInt32 is better is to me like asking if you should
standardize on using sine or cosine... you use whichever fits what you are
doing.

If some shop did standardize on one or the other for some reason, so what?
I'd be more inclined to take any code that does it either way and rip out
the conversion and replace it with code that leaves True and False as
boolean values and handles assigning a numberic value.

> NET will probably be Microsoft's preferred programming platform for the
> next 5-10 years. Will -1 make things a little easier to port from VB6 to
> VB.NET? Yes. I don't deny that.

We agree on something anyway. <g>

> But 3-5 years from now, will that really matter? Probably not. Changing
VB's
> True from -1 to 1 is a one time conversion problem.

No, it's years of deciding finally that the app can't be properly supported
in VB6 any more and needs to be redone. While I expect that to mean
scrapping and rewriting much of it I'd also expect to be able to import
large chunks as-is. It's also years of going back and forth maintaining
both VB6 and VB.Net apps where the exact same code giving very different
results is going to cause a lot of stupid bugs. It's years of newbies
taking code snippets from web sites and newsgroups and not understanding
that the language isn't the same even though the code compiles cleanly...

> But once it's done, it's
> done. An inconsistant value for True is a long-term problem we'll be
dealing
> with as long as .NET exists. I would much rather get it over with now
rather
> than drag it out. In short, we're sacrificing the long term for short-term
> gain.

Changing from -1 to +1 sacrificies long-term maintenance sanity for no gain
that I see.

> And keep in mind that some or at least many VB6 programs will never be
ported
> to .NET. They'll be rewritten. I can't predict the future, but if this
turns
> out to be the case, then we've sacrificed the long-term term for no short
> term gain. In which case, we've gained nothing for the trade-off.

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.

> > Simply declaring that
> >+1 is a "better" value than -1 and that code that has been working fine
> for
> >years is wrong or poor quality strikes me as highly arrogant.
>
> Bob, this has nothing to do with whether it's 1 or -1, just as long as
it's
> consistant. I honestly don't care what True is just as long as it's the
same
> across .NET and within VB.NET programs. And right now it is NOT
consistant.

That wasn't aimed specifically at you - apologies if it came across that
way. As for being consistent, it depends on how you look at it. I see CInt
consistent across VB versions and the Convert object consistent across
dotnet platforms and no reason at all for them to be consistent with each
other which leaves no inconsistency.