Comment On syntax.vb

For nearly two years, Hank T. tried his best to avoid the CEE system. He even made an effort to not know what CEE stood for (though he was pretty sure it was Customer something Engagement). But alas, the inevitable happened and he was finally tasked with fixing a bug in CEE. [expand full text]
« PrevPage 1 | Page 2Next »

Re: syntax.vb

2008-09-19 08:07 • by Aaron (unregistered)
Public Sub begin_comment()
begin()
End
End Sub

Re: syntax.vb

2008-09-19 08:17 • by Gerino
The goggles!
They do none()!

Re: syntax.vb

2008-09-19 08:24 • by 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)

:-þ

Re: syntax.vb

2008-09-19 08:26 • by JonC
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

Re: syntax.vb

2008-09-19 08:31 • by Me (unregistered)
I WANNA KNOW WHAT begin() DOES!!!!!

Re: syntax.vb

2008-09-19 08:32 • by Me (unregistered)
218320 in reply to 218319
Me:
I WANNA KNOW WHAT begin() DOES!!!!!


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

Re: syntax.vb

2008-09-19 08:33 • by fuzzix
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!

Re: syntax.vb

2008-09-19 08:34 • by David (unregistered)
218322 in reply to 218319
Me:
I WANNA KNOW WHAT begin() DOES!!!!!

It's an alias for goggles()

Re: syntax.vb

2008-09-19 08:36 • by bg (unregistered)
218323 in reply to 218319
Me:
I WANNA KNOW WHAT begin() DOES!!!!!
I WANT YOU TO SHOW MEEE...

Re: syntax.vb

2008-09-19 08:40 • by derfy (unregistered)
218326 in reply to 218323
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.

Re: syntax.vb

2008-09-19 08:44 • by iusto (unregistered)
The real WTF is giving a "VB programmer" VB.NET and turning them lose to ruin the name of .NET :(

Re: syntax.vb

2008-09-19 08:45 • by blub (unregistered)
TRWTF is not using VB6!

Re: syntax.vb

2008-09-19 08:52 • by Grammatischer Sturmführer (unregistered)
218330 in reply to 218327
iusto:
and turning them lose


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

Re: syntax.vb

2008-09-19 09:09 • by 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.

Re: syntax.vb

2008-09-19 09:11 • by 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.

Re: syntax.vb

2008-09-19 09:15 • by snoofle
218335 in reply to 218332
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.

Re: syntax.vb

2008-09-19 09:16 • by 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?

Re: syntax.vb

2008-09-19 09:17 • by gabba
218337 in reply to 218334
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.

Re: syntax.vb

2008-09-19 09:21 • by Bruce (unregistered)
218338 in reply to 218332
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...

Re: syntax.vb

2008-09-19 09:21 • by snoofle
218339 in reply to 218337
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

Re: syntax.vb

2008-09-19 09:26 • by snoofle
218340 in reply to 218338
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!

Re: syntax.vb

2008-09-19 09:33 • by 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.

Re: syntax.vb

2008-09-19 09:37 • by h (unregistered)
218342 in reply to 218316
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..

Re: syntax.vb

2008-09-19 09:38 • by JiffyPop (unregistered)
218343 in reply to 218338
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.

Re: syntax.vb

2008-09-19 09:42 • by 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*

Re: syntax.vb

2008-09-19 09:49 • by blah (unregistered)
Maybe author read an article on AOP and tried to cram it into the app and then gave up.

Re: syntax.vb

2008-09-19 09:54 • by 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!

Re: syntax.vb

2008-09-19 09:56 • by Zab Brannigan (unregistered)
218348 in reply to 218335
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.

Re: syntax.vb

2008-09-19 09:59 • by sir_flexalot
Now that is some serious WTF code! I love the 'recreate the language with the language' ones.

Re: syntax.vb

2008-09-19 10:00 • by OneMHz
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.

Re: syntax.vb

2008-09-19 10:02 • by JM (unregistered)
218352 in reply to 218339
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...

Re: syntax.vb

2008-09-19 10:03 • by akatherder
218353 in reply to 218340
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.

Re: syntax.vb

2008-09-19 10:04 • by 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?

Re: syntax.vb

2008-09-19 10:09 • by fruey
218357 in reply to 218335
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.

Re: syntax.vb

2008-09-19 10:19 • by TopCod3r
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.

Th Goggles

2008-09-19 10:20 • by Code Slave
I'd be happy if the goggles did nothing... instead they magnify and intensify!!!! Arg!!! My retinas be burned to a crisp!

Re: syntax.vb

2008-09-19 10:22 • by TopCod3r
218362 in reply to 218355
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?

Re: syntax.vb

2008-09-19 10:22 • by DaveAronson
218363 in reply to 218332
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....

Re: syntax.vb

2008-09-19 10:23 • by snoofle
218364 in reply to 218348
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!

Re: syntax.vb

2008-09-19 10:26 • by snoofle
218366 in reply to 218363
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.

Re: syntax.vb

2008-09-19 11:11 • by Flagger (unregistered)
218379 in reply to 218341
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.

Re: syntax.vb

2008-09-19 11:40 • by Some dude (unregistered)
TRWTF is VB. I'm surprised nobody has recognized that, yet.

IQ

2008-09-19 11:45 • by jDeepBeep (unregistered)
I lost about 4 IQ points, permanently, from reading through that.

Re: syntax.vb

2008-09-19 12:07 • by 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...

Re: syntax.vb

2008-09-19 12:29 • by Satanicpuppy
218401 in reply to 218332
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.

Re: syntax.vb

2008-09-19 12:31 • by Satanicpuppy
218402 in reply to 218357
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.

Re: syntax.vb

2008-09-19 12:52 • by 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.

Re: syntax.vb

2008-09-19 12:59 • by 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.

Re: syntax.vb

2008-09-19 13:03 • by Maurits
What's wrong with in_? Seems reasonable to me. The 20 methods could have been generated code.

Re: syntax.vb - even more elegant in_()

2008-09-19 13:52 • by gisTimmy (unregistered)
218417 in reply to 218316
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)
« PrevPage 1 | Page 2Next »

Add Comment