• (cs) in reply to DJDanny
    DJDanny:
    [image] Stan Rogers wrote:
    Folks, there's no such thing as a bad programming language.


    Indeed, this I agree with. However, there are languages in existance which do nothing to encourage you to program in a decent way - they let you get away with too much rubbish, and this is the problem with VB.
  • (cs) in reply to Stan Rogers

    I would dearly love to know what happened to the scathing text that was in that comment. I'll repeat it here:

    NO language encourages anyone to program in a decent way. NONE. (Strongly typed languages merely encourage strongly-typed WTFs and a lot of unnecessary casting.) There is as much room for bad practices in C, C++, Perl, Python, Java, SmallTalk, Prolog, COBOL and FORTRAN as there is in VB.

    VB (including VBA), though, is nearly ubiquitous. One doesn't need the same impetus to get started, and the "visual" aspect means that one can have a well-behaved UI without having equally well-behaved code behind it. That means that non-programmers can get a bit further in VB than they might have been able to in C. HOWEVER, one can do the same thing in C# or J# in VS.NET.

    I would bet that there are a fair number of actual, honest-to-goodness VB-only developers out there who could code you into the dust. Knowing only one language (and its system hooks) implies nothing more than a lack of experience in other environments. It doesn't mean they haven't read and grokked Knuth. There is absolutely zero room for language snobbery (unless you actually understand Iverson notation). All are equally good and bad.

    It ain't the hammer. It's the carpenter.

  • (unregistered) in reply to
    :
    And that he implements all 255 possible values and still makes a default.


    Didn't anyone notice he didn't implemented all 255 possible values?
       Case Chr(64) 
        Buffer = Buffer & "%40"
       Case Chr(91)
        Buffer = Buffer & "%5B"
    See, normal letters aren't encoded. But since nobody has seen this, it would be better if he specified all letters as Buffer = Buffer & "A", Buffer = Buffer & "B", ...
    And he'd get more money (obviously being paid per line)
  • (unregistered) in reply to RJ
    RJ:
    ...notice it is still in System.Web, so if you are not developing an ASP page you must link a 1.2 Meg assembly just to be able to use a simple static encoding function...


    Dynamically linking to an assembly which is installed with the framework, and thus already on the system.

    System.Web is a logical namespace for things which deal with URLs...
  • (unregistered) in reply to
    :
    [image]  wrote:
    Check out Case 32:
      Case Chr(32) 
        Buffer = Buffer & "+"

    Huh? ASCII 32 is a space, and it can be encoded as a +, or %20, both work fine.


    He did that to save his fingers from the extra typing.  "+" is only one character and "%20" is 3 characters.  He reduced his typing by 67%!  What an efficient coder!
  • (cs) in reply to
    anon:
    Dynamically linking to an assembly which is installed with the framework, and thus already on the system.

    On the harddrive, yes.  In memory, probably not.

    anon:
    System.Web is a logical namespace for things which deal with URLs...

    That is true.  Though Microsoft.IIS may be a better name for that assembly.
  • (cs)

    Stan --

    Well-said.  I 100% agree with you.

  • (unregistered) in reply to
    :
    [image]  wrote:
    Check out Case 32:
      Case Chr(32) 
        Buffer = Buffer & "+"

    Huh? ASCII 32 is a space, and it can be encoded as a +, or %20, both work fine.
  • (unregistered)

    This article seems to have some similarities:

    http://www.asp101.com/articles/jason/smartsurf/default.asp

  • (cs)

    It seems to be pretty fast code, though. That is, if the compiler optimizes the case statement to jump directly to the correct line. Perhaps the one who wrote it tried to speed it up... Or at least attempted to make it faster.[:@]

  • (cs)

    Jorn (sorry about the o) was paid 200-400% less than the original coder?  Surely that's tongue-in-cheek; I hope he didn't pay to fix it.

  • (cs) in reply to DWalker

    Oops.  I see that has been covered.  Sorry!

  • (unregistered)

    Wow... And I thought it was bad the other day when a fellow classmate (mind you, this is in a senior level computer science course in a top 5 school for CS) used a switch with 26 cases to do upper casing.

  • discount (unregistered)

    You are seriously an idiot.


    Dim URL As New System.Uri("HTTP://LOL.COM/THERE ARE SPACES IN THIS FILE.HTML", False)
    Debug.WriteLine(URL.AbsoluteUri)


    You should not be allowed to code.

    This forum sucks too.
  • (cs) in reply to Ben Hutchings
    Ben Hutchings:
    Now it's possible to play safe by encoding space as "%20" and "+" as "%2B" but this might be undesirable.


    I've run into this before but I'll be hornswoggled if I can come up with a situation where it is undesirable to encode space as %20.  + is correctly encoded as %2B by Server.URLEncode

    I've seriously thought about creating a RealURLEncode function

    Function RealURLEncode(s)
        RealURLEncode = Replace(Server.URLEncode(s), "+", "%20")
    End Function

    and RealHTMLEncode function
    Function RealHTMLEncode(s)

        RealHTMLEncode = Replace(Server.HTMLEncode(s), vbCrLf, "<br />")

    End Function

  • (cs) in reply to Rob

    So, there are some stupid people who program vb.  Don't generalize like that though.  Not all 'pure' vb programmers are all that bad.  I'm a 'pure' vb(.net) programmer (I dabble in c# and c++).  I would never do something as stupid as that, most other 'pure' vb programmers I know wouldn't either.  (This could just be cause I use .net and most of the idiots still use vb6, but that's fine)

  • me (unregistered)

    OH MY GOD

Leave a comment on “Worst. Reimplementation. Ever.”

Log In or post as a guest

Replying to comment #:

« Return to Article