• Aaron (unregistered)

    Public Sub begin_comment() begin() End End Sub

  • (cs)

    The goggles! They do none()!

  • bbobb (unregistered)

    I see the WTF in the in_() functions. They really only needed the first one; the rest were redundant and limiting. What if they had 22 items? They could have solved it much more elegantly as:

    result = in_(v,p1) OrElse in_(v,p2) OrElse in_(v,p3) ... OrElse in_(v,p20) OrElse in_(v,p21) OrElse in_(v,p22)

    :-þ

  • (cs)

    This is one of the first entries in a while to actually make me say WTF!

    Not least for the fact that the developer hasn't heard of ParamArrays in VB.NET The whole thing is a complete trainwreck

  • Me (unregistered)

    I WANNA KNOW WHAT begin() DOES!!!!!

  • Me (unregistered) in reply to Me
    Me:
    I WANNA KNOW WHAT begin() DOES!!!!!

    Oh wait... it does nothing. Never mind.

  • (cs)
    More accurately, they were the Long set of _in() methods.
    Aren't they in_() methods?
    Though he suspected that the ECC system was yet another tentacle of the great Codethulhu...
    Isn't it CEE?

    The quality of MFD is seeping into the articles! NOOO!

  • David (unregistered) in reply to Me
    Me:
    I WANNA KNOW WHAT begin() DOES!!!!!
    It's an alias for goggles()
  • bg (unregistered) in reply to Me
    Me:
    I WANNA KNOW WHAT begin() DOES!!!!!
    I WANT YOU TO SHOW MEEE...
  • derfy (unregistered) in reply to bg

    And now I'm going to have that running through my head all day. :(

    Hrm, 'gravis'. Two blasts from the past. Now all I need is a rickroll and my Friday is complete.

  • iusto (unregistered)

    The real WTF is giving a "VB programmer" VB.NET and turning them lose to ruin the name of .NET :(

  • blub (unregistered)

    TRWTF is not using VB6!

  • Grammatischer Sturmführer (unregistered) in reply to iusto
    iusto:
    and turning them lose

    Wow, one so seldom sees confusing 'lose' and 'loose' this way. Usually it is the other way around.

  • Zab Brannigan (unregistered)

    This kind of pisses me off! If I saw this at work I become (more?) physically and verbally abusive. I've seen something similar. We had a consultant that was Unix bigot. He created a Unix shell for DOS on his PC by using .bat files and renaming system commands. Of course, after seeing this, another programmer made a DOS shell for Unix.

  • (cs)

    While I agree that overloading everything is horrifying, I can see the need for optional begin() and end() methods, though not implemented quite this way...

    Think about it, if you rename them preProcessing() and postProcessing(), they make nice placeholders for data transformations. Most app servers and messaging systems have hooks for these sorts of things, except that they implement it properly.

  • (cs) in reply to Zab Brannigan
    Zab Brannigan:
    ...created a Unix shell for DOS on his PC by using .bat files and renaming system commands. Of course, after seeing this, another programmer made a DOS shell for Unix.
    As someone who frequently has to work in both environments, I can see why he did this, and it has nothing to do with elitism.

    You know two different sets of commands to perform the same actions. Invariably, you end up typing the Unix commands when in a DOS window, and the DOS commands when in a Unix window. It's just easier to have aliases or scripts that implement the other set of commands in each environment so no matter which command you enter, it still performs your intended action.

  • Bruce (unregistered)

    The code isn't so bad. I've seen MUCH worse. The Begin() is obviously there for debugging purposes so that they could put a logging statement into the Begin function when desired. That's not the right way to do it in .NET, but it would work.

    The in_ functions are interesting - doesn't VB.Net have VarArgs?

  • (cs) in reply to snoofle
    snoofle:
    While I agree that overloading everything is horrifying, I can see the need for optional begin() and end() methods, though not implemented quite this way...

    Think about it, if you rename them preProcessing() and postProcessing(), they make nice placeholders for data transformations. Most app servers and messaging systems have hooks for these sorts of things, except that they implement it properly.

    Good thinking. But why stop there? You're gonna need a afterPreProcessing(), a midProcessing(), a beforePostProcessing(), and perhaps many others. Gotta plan ahead.

  • Bruce (unregistered) in reply to Zab Brannigan
    Zab Brannigan:
    This kind of pisses me off! If I saw this at work I become (more?) physically and verbally abusive. I've seen something similar. We had a consultant that was Unix bigot. He created a Unix shell for DOS on his PC by using .bat files and renaming system commands. Of course, after seeing this, another programmer made a DOS shell for Unix.
    I worked with a programmer who didn't like C++ very much so he defined preprocessor macros so that he could make his code look like FORTRAN. Now that was a WTF! #define EQ == #define begin { #defing end } etc...
  • (cs) in reply to gabba
    gabba:
    snoofle:
    While I agree that overloading everything is horrifying, I can see the need for optional begin() and end() methods, though not implemented quite this way...

    Think about it, if you rename them preProcessing() and postProcessing(), they make nice placeholders for data transformations. Most app servers and messaging systems have hooks for these sorts of things, except that they implement it properly.

    Good thinking. But why stop there? You're gonna need a afterPreProcessing(), a midProcessing(), a beforePostProcessing(), and perhaps many others. Gotta plan ahead.

    I know you're joking, but some messaging systems I've worked on actually had the following:

    - pre processing hook
- hook after underlying system starts but before getting to
  your transformation
- hook after transformation but before sending message
- hook after sending message but before cleanup
- hook after cleanup

and then the same thing on the receiving side
  • (cs) in reply to Bruce
    Bruce:
    I worked with a programmer who didn't like C++ very much so he defined preprocessor macros so that he could make his code look like FORTRAN. Now that was a WTF! #define EQ == #define begin { #defing end } etc...
    A guy I worked with when we migrated from Pascal to C (very long time ago) did this to turn C into Pascal-looking code.

    I can sort of see why someone would be psychologically attached to a language, but folks, ya gotta learn to let go!

  • Bob (unregistered)

    Hang on a minute, you're saying that every method in the codebase calls "begin()" but the begin method actually does nothing? Wow, just wow. You can't even argue that this is for some pre processing operation, since the same begin method is called from every other method. Unless every single method in the system requires the same pre processing which is wholly unrealistic and would undoubtedly hint at a far bigger WTF that the ones on display today. Just what the fu... oh, there it is.

  • h (unregistered) in reply to bbobb
    bbobb:
    I see the WTF in the in_() functions. They really only needed the first one; the rest were redundant and limiting. What if they had 22 items? They could have solved it much more elegantly as:

    result = in_(v,p1) OrElse in_(v,p2) OrElse in_(v,p3) ... OrElse in_(v,p20) OrElse in_(v,p21) OrElse in_(v,p22)

    :-þ

    I don't get why he didn't reuse his code for more elegantly problem solvings...

    Public Function in_(ByVal v As Long, ByVal p1 As Long, ByVal p2 As Long, _
                    ByVal p3 As Long, ByVal p4 As Long, ByVal p5 As Long, _ 
                    ...
                    ByVal p18 As Long, ByVal p19 As Long, ByVal p20 As Long _
                    ) As Boolean
    begin()
    Return in_(v,p1,p2,p3,p4,p5,p6,p7,p8,p9,p10) OrElse in_(v,p11,p12,p13,p14,p15,p16,p17,p18,p19,p20)
End Function 'in_(20)

    Makes much more sense to me - best practices at their... best..

  • JiffyPop (unregistered) in reply to Bruce

    The whole data acquisition system at the lab I worked at had C/C++ as FORTRAN macros. It wasn't used by the people writing the underlying code (including a custom Linux kernel), but the physicists abused it appropriately. Surprised the heck out of me when I discovered it, though.

  • cod3_complete (unregistered)

    WTF just WTF. This crap code looks surprisingly familiar to some kludges I've seen before. I would bet 10 bucks that this moron was a former vb6 coder who was 'drafted' to work with VB.NET. Sigh

  • blah (unregistered)

    Maybe author read an article on AOP and tried to cram it into the app and then gave up.

  • bluprintz (unregistered)

    Looks like someone is trying to implement Aspect Oriented Programming... for Visual Basic.

    The begin() is obviously addressing some cross-cutting concerns.

    Run! Run away now!

  • Zab Brannigan (unregistered) in reply to snoofle
    snoofle:
    Zab Brannigan:
    ...created a Unix shell for DOS on his PC by using .bat files and renaming system commands. Of course, after seeing this, another programmer made a DOS shell for Unix.
    As someone who frequently has to work in both environments, I can see why he did this, and it has nothing to do with elitism...
    Based on a single point of data you have drawn a reasonable conclusion. I worked with the fellow a couple of years. I believe his brain cavity is filled with Portland cement.
  • (cs)

    Now that is some serious WTF code! I love the 'recreate the language with the language' ones.

  • (cs)

    if(boolVal)

    No...

    if(true_(boolVal))

    No...

    if(true_(boolVal) = _true(True))

    No...

    if(true_(boolVal) = _true(_true(True)))

    .... damnit, now I need to write in_ methods for boolean types. I'll need 5 overloads for true, false, FileNotFound, -1, Tuesday, not set and unknown.

  • JM (unregistered) in reply to snoofle
    snoofle:
    gabba:
    snoofle:
    While I agree that overloading everything is horrifying, I can see the need for optional begin() and end() methods, though not implemented quite this way...

    Think about it, if you rename them preProcessing() and postProcessing(), they make nice placeholders for data transformations. Most app servers and messaging systems have hooks for these sorts of things, except that they implement it properly.

    Good thinking. But why stop there? You're gonna need a afterPreProcessing(), a midProcessing(), a beforePostProcessing(), and perhaps many others. Gotta plan ahead.

    I know you're joking, but some messaging systems I've worked on actually had the following:

    - pre processing hook
- hook after underlying system starts but before getting to
  your transformation
- hook after transformation but before sending message
- hook after sending message but before cleanup
- hook after cleanup

    and then the same thing on the receiving side

    And importantly, this is not a WTF, it's what's good for you -- as long as actually implementing each of those hooks is optional, of course. Hooks are good. Love the hooks. Good for extensibility.

    Of course, we are talking about messaging systems here. Doing this for every method is either insanity (if you do it manually) or aspect-oriented programming (if you do it automatically). The jury's still out on the usefulness of the latter...

  • (cs) in reply to snoofle
    snoofle:
    Bruce:
    I worked with a programmer who didn't like C++ very much so he defined preprocessor macros so that he could make his code look like FORTRAN. Now that was a WTF! #define EQ == #define begin { #defing end } etc...
    A guy I worked with when we migrated from Pascal to C (very long time ago) did this to turn C into Pascal-looking code.

    I can sort of see why someone would be psychologically attached to a language, but folks, ya gotta learn to let go!

    They get real pissy when you do a search and replace.

    When I was a sysadmin, we all had our "specialty" but we all worked on UNIX and Windows systems. We had the informal standard of turning windows terminals one color and UNIX the other color (white on black vs. black on white) and that helped out surprisingly well to keep you in the right mindset of whether to use ls or dir.

  • rg (unregistered)

    I think the guy had good intentions with the begin()... end() stuff. Those would make good debugging and tracing hooks, BUT he could not figure out, because it's impossible, how to put in a single end() call and still do a return someexpression from multiple places..

    I would not have a big problem with having just one layer of abstraction on the equality tests, but having it go many times wide and deep is a bit much. Especially since the code does not really do anything. Maybe this guy was being paid by the line?

  • (cs) in reply to snoofle
    snoofle:
    Zab Brannigan:
    ...created a Unix shell for DOS on his PC by using .bat files and renaming system commands. Of course, after seeing this, another programmer made a DOS shell for Unix.
    As someone who frequently has to work in both environments, I can see why he did this, and it has nothing to do with elitism.

    You know two different sets of commands to perform the same actions. Invariably, you end up typing the Unix commands when in a DOS window, and the DOS commands when in a Unix window. It's just easier to have aliases or scripts that implement the other set of commands in each environment so no matter which command you enter, it still performs your intended action.

    Personally I find it usually helps when I type "ls" and I get an error, to remind me that I'm in DOS.

    Because one day, I might be in DOS somewhere else and will not have my batch files. Or vice versa with a POSIX bash shell, or something.

  • (cs)

    TRWTF is that Hank doesn't understand OO programming in VB. It is obvious, to me anyways, that begin() is implemented in another class that inherits from this one, but is not shown. All methods in VB are virtual, and this WTF leaves out important details in determining if the WTF is in the code or in Hank's grossly inadequate VB knowledge.

  • (cs)

    I'd be happy if the goggles did nothing... instead they magnify and intensify!!!! Arg!!! My retinas be burned to a crisp!

  • (cs) in reply to rg
    rg:
    I think the guy had good intentions with the begin()... end() stuff. Those would make good debugging and tracing hooks, BUT he could not figure out, because it's impossible, how to put in a single end() call and still do a return someexpression from multiple places..

    Wow, you are a walking WTF! Ever hear of Try/Catch/FINALLY?

  • (cs) in reply to Zab Brannigan
    Zab Brannigan:
    We had a consultant that was Unix bigot. He created a Unix shell for DOS on his PC by using .bat files and renaming system commands.
    Sounds like a wannabe, who never heard of Cygwin.
    Of course, after seeing this, another programmer made a DOS shell for Unix.
    Not surprising. Coughcough years ago, when I were a lad, in college, a bunch of us made (and traded) alias-scripts so we could use our familiar TOPS-20 commands when we got access to a Unix box. Gotta admit, the command names do tend to be rather cryptic....
  • (cs) in reply to Zab Brannigan
    Zab Brannigan:
    I worked with the fellow a couple of years. I believe his brain cavity is filled with Portland cement.
    I too have had the, ahem, pleasure, of working with someone like that. Thanks for the laugh!
  • (cs) in reply to DaveAronson
    DaveAronson:
    Sounds like a wannabe, who never heard of Cygwin.
    It's possible he's heard of it, but is unable to install it (some places restrict installation of software).

    I would love to have cygwin, but can't install it, so I have a bin directory full of batch files implementing unix command equivalents... especially useful for stuff that doesn't have DOS equivalents.

  • Flagger (unregistered) in reply to Bob
    Bob:
    Hang on a minute, you're saying that every method in the codebase calls "begin()" but the begin method actually does nothing? Wow, just wow. You can't even argue that this is for some pre processing operation, since the same begin method is called from every other method. Unless every single method in the system requires the same pre processing which is wholly unrealistic and would undoubtedly hint at a far bigger WTF that the ones on display today. Just what the fu... oh, there it is.
    You underestimate the power of global variables.
  • Some dude (unregistered)

    TRWTF is VB. I'm surprised nobody has recognized that, yet.

  • jDeepBeep (unregistered)

    I lost about 4 IQ points, permanently, from reading through that.

  • yet another anonymous coward (unregistered)

    true_(), false_(), remainder() etc are not WTF, because in VB.NET, as far as I remember it (I'm not VB programmer) functions are first-class objects, but operators aren't. So if you need to generate some code at runtime they may come useful. Or not.

    begin() is WTF because having dummy calls just everywhere is probably greatly affecting the code's performance. It can be used for some hook system, though.

    in_() is a genuine WTF, because it really should be implemented with proper Set datatype with polyvariadic helper functions, so new sets could be generated and checked by some simple Set(1,2,3,4,5).Contains(2). If sets are homogeneous, generics should help with strongly-typed collections, like SetOf<Integer>, further improving code quality.

    Eh, and my English is probably a WTF too...

  • (cs) in reply to Zab Brannigan
    Zab Brannigan:
    This kind of pisses me off! If I saw this at work I become (more?) physically and verbally abusive. I've seen something similar. We had a consultant that was Unix bigot. He created a Unix shell for DOS on his PC by using .bat files and renaming system commands. Of course, after seeing this, another programmer made a DOS shell for Unix.

    I work on Unix, Windows, and MPE/iX systems constantly, which means I'm constantly unable to list the files in a directory because I type "LISTF" or "ls -al" or "DIR" without thinking.

    So yea, I have those things aliased with batch files, shell scripts, and actual aliases, so regardless which system I'm in, they all work, and I don't derail my train of thought for the sake of some trivial piece of syntax.

    If you worked on multiple OS's this would seem normal, and since the commands don't actually overlap at all, your snobbery is completely unnecessary.

    If he was really just a snob, he'd have used cygwin.

  • (cs) in reply to fruey
    fruey:
    snoofle:
    Zab Brannigan:
    ...created a Unix shell for DOS on his PC by using .bat files and renaming system commands. Of course, after seeing this, another programmer made a DOS shell for Unix.
    As someone who frequently has to work in both environments, I can see why he did this, and it has nothing to do with elitism.

    You know two different sets of commands to perform the same actions. Invariably, you end up typing the Unix commands when in a DOS window, and the DOS commands when in a Unix window. It's just easier to have aliases or scripts that implement the other set of commands in each environment so no matter which command you enter, it still performs your intended action.

    Personally I find it usually helps when I type "ls" and I get an error, to remind me that I'm in DOS.

    Because one day, I might be in DOS somewhere else and will not have my batch files. Or vice versa with a POSIX bash shell, or something.

    It's not like he doesn't know the difference. But it saves a ton of time in the long run to have that stuff just work regardless of the system.

  • Sean D (unregistered)

    The real WTF is that he only has begin() and end(). Where's "middle()"? Or how about "keep_going()"?

    If you don't tell your code to keep running, it's just going to sit there doing nothing.

  • Steve (unregistered)

    Oh my.

    I wonder if some of this isn't an artifact of some kind of crude code instrumentation. Not being a VB programmer, I'm not sure what facilities there are for tracking function/method usage and/or timing of routines (I assume there is some) but in that context this make some vague amount of sense.

    It may have seemed a good idea at the time.

    Either that or the programmer was completely bonkers.

  • (cs)

    What's wrong with in_? Seems reasonable to me. The 20 methods could have been generated code.

  • gisTimmy (unregistered) in reply to bbobb
    bbobb:
    I see the WTF in the in_() functions. They really only needed the first one; the rest were redundant and limiting. What if they had 22 items? They could have solved it much more elegantly as:

    result = in_(v,p1) OrElse in_(v,p2) OrElse in_(v,p3) ... OrElse in_(v,p20) OrElse in_(v,p21) OrElse in_(v,p22)

    :-þ

    Even more elegant:

    Public Function in_(ByVal v As Long, ByVal p1 As Long) As Boolean begin() Return v = p1 End Function 'in_(1)

    Public Function in_(ByVal v As Long, ByVal p1 As Long, ByVal p2 As Long) As Boolean begin() Return in_(v, p1) OrElse in_(v, p2) End Function 'in_(2)

    Public Function in_(ByVal v As Long, ByVal p1 As Long, ByVal p2 As Long, _ ByVal p3 As Long) As Boolean begin() Return in_(v, p1, p2) OrElse in_(v, p3) End Function 'in_(3)

    Public Function in_(ByVal v As Long, ByVal p1 As Long, ByVal p2 As Long, _ ByVal p3 As Long, ByVal p4 As Long) As Boolean begin() Return in_(v, p1, p2, p3) OrElse in_(v, p4) End Function 'in_(4)

Leave a comment on “syntax.vb”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article