Bad programming practices encouraged.... namely VB! - Page 5


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 5 of 7 FirstFirst ... 34567 LastLast
Results 61 to 75 of 91

Thread: Bad programming practices encouraged.... namely VB!

  1. #61
    Kathleen Dollard-Joeris Guest

    Re: Bad programming practices encouraged.... namely VB!

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



  2. #62
    Kunle Odutola Guest

    Re: Bad programming practices encouraged.... namely VB!


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





  3. #63
    Rick Barnett Guest

    Re: Bad programming practices encouraged.... namely VB!

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





  4. #64
    Mike Mitchell Guest

    Re: Bad programming practices encouraged.... namely VB!

    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

  5. #65
    Mike Mitchell Guest

    Re: Bad programming practices encouraged.... namely VB!

    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

  6. #66
    Gregor R. Peisker Guest

    Re: Bad programming practices encouraged.... namely VB!

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





  7. #67
    Kunle Odutola Guest

    Re: Bad programming practices encouraged.... namely VB!

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




  8. #68
    Kunle Odutola Guest

    Re: Bad programming practices encouraged.... namely VB!


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




  9. #69
    Zane Thomas Guest

    Re: Bad programming practices encouraged.... namely VB!

    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

  10. #70
    Bob Butler Guest

    Re: Bad programming practices encouraged.... namely VB!


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





  11. #71
    Patrick Troughton Guest

    Re: Bad programming practices encouraged.... namely VB!


    "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

  12. #72
    Patrick Troughton Guest

    Re: Bad programming practices encouraged.... namely VB!


    "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

  13. #73
    Mark Hurd Guest

    Re: Bad programming practices encouraged.... namely VB!

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



  14. #74
    Mark Hurd Guest

    Re: Bad programming practices encouraged.... namely VB!

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



  15. #75
    Bob Butler Guest

    Re: Bad programming practices encouraged.... namely VB!


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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center