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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 6 of 7 FirstFirst ... 4567 LastLast
Results 76 to 90 of 91

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

  1. #76
    Bob Butler Guest

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


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




  2. #77
    Jonny Guest

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

    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.



  3. #78
    Larry Serflaten Guest

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


    "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




  4. #79
    Jonny Guest

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

    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



  5. #80
    Bob Butler Guest

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


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




  6. #81
    Kunle Odutola Guest

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

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



  7. #82
    Vlad Ivanov Guest

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


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

    :-)

  8. #83
    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: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

  9. #84
    Bob Butler Guest

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


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




  10. #85
    Rob Teixeira Guest

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


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



  11. #86
    Kunle Odutola Guest

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


    "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





  12. #87
    Gregor R. Peisker Guest

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

    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



  13. #88
    Gregor R. Peisker Guest

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

    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



  14. #89
    Dan Barclay 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:

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

  15. #90
    Mike Mitchell Guest

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

    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

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