Comment On Take-home Trouble

:)

These don't seem that bad (apart from C&P input validation and I'm intruiged about s1, s2 and s3).....

Now, Alex, why don't you post the actual test (since its not production code) and see what other ppl come up with.

I'm sure some will be Brillant.

ps, I have a small function over here which I'll send soon which made my head bleed.

Although some would argue that developers/programmers have the need for creativity, this is not helping the cause.

Alex Papadimoulis:

Nikolay was trying to figure why one candidate turned in only this code file, when the assignment was a small app that demonstrated database connectivity in Delphi ...

/*

** hellowin.csx (C#) - example: axwscript hellowin.csx

** Demonstrates the use of Windows Forms to display a messagebox

**

** See also hello.csx

*/

Maybe this person didn't think anyone was going to look at it anyway. 

So tell me "Steve-o", instead of just generic oneliners, why don't you point out the wrongdoings in the examples?

Oh yeah, that's right, like 99% of the readers here you have no idea what you're talking about and just posting random crap thinking you then might belong to the club.

Here's a WTF: dailywtf.com evidently tries to send email without a valid "HELO". 

Alex Papadimoulis:

Nikolay was trying to figure why one
candidate turned in only this code file, when the assignment was a
small app that demonstrated database connectivity in Delphi ...

/*
** hellowin.csx (C#) - example: axwscript hellowin.csx
** Demonstrates the use of Windows Forms to display a messagebox
**
** See also hello.csx
*/

I see, Paula looking for a new job, is she?

ptomblin:

Here's a WTF: dailywtf.com evidently tries to send email without a valid "HELO". 

May  2 13:17:51 allhats postfix/smtpd[5902]: NOQUEUE: reject: RCPT from unknown[66.232.98.34]: 504 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=

Single-element HELO is explicitly allowed by RFC 821, and back-compat'ed by RFC 2821.

Anonymous:

So tell me "Steve-o", instead of just generic oneliners, why don't you point out the wrongdoings in the examples?

Oh yeah, that's right, like 99% of the readers here you have no idea what you're talking about and just posting random crap thinking you then might belong to the club.

No kidding. The comments on here make me want to scream more than the articles. Ugh.

Why did the first guy create more than one of the same function? What the hell? The function is also strewn with WTFs too.... WHAT THE HELL?!?!?!?!?!

Pascal identifiers are case-blind, aren't they? So that gets the FALSE guy mostly off the hook; it looks
stupid, but it'll compile and it'll do what it ought to at runtime --
unless Delphi diverges from normal Pascal in that respect.



Personally, I enjoy the fact that moron languages like Pascal and VB
are case blind (not to mention Microsoft's filesystems): It gives
stupid people a well-deserved kick in the teeth if they ever try to
venture beyond the apron strings. The more arbitrary barriers to entry
there are, the less chance they'll ever bullshit their way into a real
job and generate WTFs for me to waste my time on.

Edgar Plonk:

Pascal identifiers are case-blind, aren't they? So that gets the FALSE guy mostly off the hook; it looks
stupid, but it'll compile and it'll do what it ought to at runtime --
unless Delphi diverges from normal Pascal in that respect.

That's not the WTF, I think. The WTF is that the default control names
(panel1, etc) were never changed when the form or page was developed.



I think that's VB.NET, BTW.

Wait, sorry, there's no way that's VB.

GoatCheez:

Why did the first guy create more than one of the same function? What the hell? The function is also strewn with WTFs too.... WHAT THE HELL?!?!?!?!?!

I wonder if the obfuscation process caused this to be more of a WTF than it already was...

Surely, not all of the functions contained:

if pos(key,edopolm3.text)<>0 then key:=#0;

I guess if they did, then it was a serious WTF. Either way, did this candidate get hired into a management role?

Anonymous:

So tell me "Steve-o", instead of just generic oneliners, why don't you point out the wrongdoings in the examples? Oh yeah, that's right, like 99% of the readers here you have no idea what you're talking about and just posting random crap thinking you then might belong to the club.

The real WTF is that you don't realize how hypocritcal you are.  Come one, what about the code that's just a comment?  Surely you're in the 1% that can figure out that WTF.

But but but *sputter* it's only 1:45!

Alex Papadimoulis:

Nikolay was trying to figure why one candidate turned in only this code file, when the assignment was a small app that demonstrated database connectivity in Delphi ...

/*

** hellowin.csx (C#) - example: axwscript hellowin.csx

** Demonstrates the use of Windows Forms to display a messagebox

**

** See also hello.csx

*/

Classic redirection technique... If the interviewer asks you to solve a particular problem for which you're not prepared to answer, simply substitute with the answer to a different question.  "That sounds like a fascinating problem, but I'd really like to discuss the use of Windows Forms for messagebox display."

Maurits:

ptomblin:

Here's a WTF: dailywtf.com evidently tries to send email without a valid "HELO". 

May  2 13:17:51 allhats postfix/smtpd[5902]: NOQUEUE: reject: RCPT from unknown[66.232.98.34]: 504 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=

Single-element HELO is explicitly allowed by RFC 821, and back-compat'ed by RFC 2821.

Since not accepting single element HELOs drops several hundred spams a day (457 in last nights logwatch), and one legitimate mail (dailywtf), I'm not going to change my filtering.

Maurits:

Single-element HELO is explicitly allowed by RFC 821, and back-compat'ed by RFC 2821.

Sorry, but RFC 821 was superceded by RFC 1123 on this particular subject.


5.2.5 HELO Command: RFC-821 Section 3.5


The sender-SMTP MUST ensure that the domain parameter in a

HELO command is a valid principal host domain name for the

client host. As a result, the receiver-SMTP will not have to

perform MX resolution on this name in order to validate the

HELO parameter.



Now, it admittedly goes on to state that receivers must not reject mail that has an invalid HELO, so both sides are in the wrong here. Nevertheless, the HELO command MUST be followed by a domain name.

I don't see any problem with the for/case example.  Execution of the case statement is dependent on a test that varies on a loop index, as do the bodies of each labeled statement.

Why is this being held up as an example of WTF?  Can anbody come up with a more elegant solution (not that I think this one is bad)?

Anonymous:

So tell me "Steve-o", instead of just generic oneliners, why don't you point out the wrongdoings in the examples?

Oh yeah, that's right, like 99% of the readers here you have no idea what you're talking about and just posting random crap thinking you then might belong to the club.

It takes more than posting random crap to get in; you have to beat a dead horse with "brillant" or "FileNotFound" jokes.

That reminds me, Alex, I haven't received my card yet.

Jojosh_the_Pi:

That reminds me, Alex, I haven't received my card yet.

You do not appear to be covered in gobs of horse flesh. Try harder!

Otto:

Sorry, but RFC 821 was superceded by RFC 1123 on this particular subject.

RFC 2821 in turn supersedes RFC 1123 (the mail bits of it, anyway) and reinstates the legality of the RFC 821 behavior:

   "... Older client SMTP systems MAY, as discussed above,
   use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
   support the HELO command and reply properly to it." (my emphasis

Anonymous:

I don't see any problem with the for/case example.  Execution of the case statement is dependent on a test that varies on a loop index, as do the bodies of each labeled statement. Why is this being held up as an example of WTF?  Can anbody come up with a more elegant solution (not that I think this one is bad)?

Because it's using a loop and variable along with conditional jumps to excute what is essentially a never changing block of code. Unroll the loop, and the code being run never, ever, varies. Why not just change it from this annoying and hard to manage structure into a static 13 statements? It'll be both faster and less confusing.


On an only marginally related note, I've seen a variation of the for-case structure before which made some sense (for small cases), but which was no less annoying.

It was an infinite while-case. The person who wrote it called it a "state machine", which made me kinda want to hit him.

Basically it was like this:
enum possibleStates = {state1, state2, state3, etc};
possibleStates currentState = state1;
while() // infinite loop
{
switch (currentState) {
case state1:
    do some stuff
    currentState = state2;
    break;
case state2:
    do some stuff
    currentState = state3;
    break
case state3:
    do some stuff
    currentState = state1;
    break;
} // end switch
} // end while

Now, this is a simple example. The actual code I was looking at was 10k+ lines long, with hundreds of possible states, and each state had not one exit point, oh no, but many possible exit points leading to other states. All the variables these states used were shared by all the other states because of scoping rules, so every variable was equivalent to being global.

Some of the wiser people forced to work on this nightmare had clearly taken some of these states and turned them into actual functions in other files, because dozens of the states consisted of nothing more than a function call passing a few variables to the function and returning the next state for the thing to go to, but the whole thing was hampered by the original "state machine" structure.

I got myself reassigned to a new project after looking at that code.

Anonymous:

I don't see any problem with the for/case example.  Execution of the case statement is dependent on a test that varies on a loop index, as do the bodies of each labeled statement.

Why is this being held up as an example of WTF?  Can anbody come up with a more elegant solution (not that I think this one is bad)?

Ok, I have absoutely no knowledge of Delphi, so maybe the language just requires code like this. When I looked at the function the first time, it just made my head hurt. That's never good. The variables are not named, and the functionality is absolutely unclear. From the function name i can only guess that it must do some input validation when a form is submitted.

On a second look, it reminded me of a Duffs device. That's great for obfuscation contests, but not for production code :-)

What is s1?
Why aren't the edit fields stored in an array to iterate over?
Isn't Delphi an OO language? Subclass the edit field object and add a doSomething() method that performs the correct action, then simply iterate over the array of fields and .doSomething() on everyone of them.
This guy is adding functionality to the class from the outside, and not taking advantage of polymorphism. That's always ugly.

What does the loop at the end do?
"   b:=false;
    for i:=1 to 13 do b:=b or s1[i];
    selection:=b;"
It's an utterly ugly way of finding out if any of the 12 elements of s1 is true. Especially when you want to set selection, and not 'b'.

Pseudo-pascal:

for i := 1 to 13 do
  if(s1[i]) {
   selection := true;
   break;
  }

Maurits:

RFC 2821 in turn supersedes RFC 1123 (the mail bits of it, anyway) and reinstates the legality of the RFC 821 behavior:

Actually, looking through RFC 821, I fail to see where it says that domain is optional in the HELO command.


HELLO (HELO)


This command is used to identify the sender-SMTP to the

receiver-SMTP. The argument field contains the host name of

the sender-SMTP.




Nowhere does it even imply that you can have a single HELO.

Well, in the example you gave, it's obviously no better than just sequentially executing state 1, 2, and 3 over again.  But in the case where each state has more than one possible following state, a state machine cam be a very useful and efficient device.  Especially when parsing input.

Bus Raker:

Anonymous:

So tell me "Steve-o", instead of just generic oneliners, why don't you point out the wrongdoings in the examples? Oh yeah, that's right, like 99% of the readers here you have no idea what you're talking about and just posting random crap thinking you then might belong to the club.

The real WTF is that you don't realize how hypocritcal you are.  Come one, what about the code that's just a comment?  Surely you're in the 1% that can figure out that WTF.

Delphi code is generally written in delphi, not C Sharp.  Based on the fact that the comments don't describe the assigned task, it was probably also cut-n-pasted from sample code off of the internet, instead of written by the applicant.

Adonoman:

Well, in the example you gave, it's obviously no better than just sequentially executing state 1, 2, and 3 over again.  But in the case where each state has more than one possible following state, a state machine cam be a very useful and efficient device.  Especially when parsing input.

Yes, for small and inoffensive cases, I agree. But not when it's for an entire multi-thousand line program. The original program looked like it had no functions, for god's sake.

Edgar Plonk:

moron languages like Pascal

Why in the world is Pascal a "Moron" language?  Because it isn't case-sensitive?  For most good programmers that little fact isn't going to matter at all.  Other than that, though, the only real differences between Delphi and C++ were mostly syntactical.  You could do just about anything in Delphi that you could in C++ (and usually faster in the days of MS VC++), and generally could do more than VB.

It might not be the best choise today for a number of reasons, but Delphi was a great, if undervalued, development tool for many, many years.

At the end of the day, I think it wiser to focus on programming principles and writing solid code than trying to argue the superiority of lanugages.  Any argument against Delphi is going to be based on popularity, not the capabilities of the tool.  But I guess that's been said before.  It just saddens me that so many people missed out on the great tool that was Delphi because it didn't gain the popularity it deserved, but that too is an old, old story.

I've been given many coding tests in t he short time I've been a software engineer.  I've written it off largely to my lack of experience and the skiddishness of employers.  Entry-level programmers can be trouble to begin with (most if not all need some guidance when they are starting out).  Employers don't want employees who write code that belongs on this website, so they are simply being more thourough.  If it's this or a company not even considering less experienced (on paper) engineers, then I'd pick this.

On the other hand, there is the other side of it.  I took so many timed tests (stressful as all hell if you go down the wrong tangent) that I started to recognize the problems from past tests.  It's like if you take the SAT too many times (or enough times, depends on your outlook).

Some of the questions were so easy that even if I nailed them it wasn't able to get me the job.  One place did give me a bit of a challenging task, and it took 10+ hours (not timed).  They wanted me to implement a string class in C++ that did copy on write and reference counting.  It was interesting to do, but it took quite a lot of work.

Now... if you are talking about giving a programming test to a more experienced programmer, then your (Alex's) opinion might be more correct.  Do what a company did for my friend.  They brought him in and paid him to work for them for a day or two.  Kind of like a trial period, only really short and a lot more fun.  He loved it, and is working for them now.  I'd recommend this over any programming test.

GalacticCowboy:

But but but *sputter* it's only 1:45!

I was thinking the same thing. You should see me after lunch, refreshing my screen... God I need a life.

GalacticCowboy:

Alex Papadimoulis:

Nikolay was trying to figure why one candidate turned in only this code file, when the assignment was a small app that demonstrated database connectivity in Delphi ...

/*

** hellowin.csx (C#) - example: axwscript hellowin.csx

** Demonstrates the use of Windows Forms to display a messagebox

**

** See also hello.csx

*/

Classic redirection technique... If the interviewer asks you to solve a particular problem for which you're not prepared to answer, simply substitute with the answer to a different question.  "That sounds like a fascinating problem, but I'd really like to discuss the use of Windows Forms for messagebox display."

This reminds me of some of the assignments my classmates handed in. The ones that didn't even try would just print something out, and maybe put in a folder with a blank floppy. Maybe they were hoping the programming fairy would take care of it...

I think they forgot to change the name of the edit box in the "if pos(key,edopolm3.text)<>0" lines.

What kind of text edit box would contain only numbers and at most, one apostropie?

R.Flowers:

GalacticCowboy:

But but but *sputter* it's only 1:45!

I was thinking the same thing. You should see me after lunch, refreshing my screen... God I need a life.

My WTF notification doesn't kick in until noon (PST).  This early one is a treat!

Also, I didn't know they coded Delphi in Delphi.  I thought they coded it in C# ... cmon!  Looks more like a T-SQL comment to me anyway, so now I assume that they code Delphi in T-SQL.

Ford351-4V:

I think they forgot to change the name of the edit box in the "if pos(key,edopolm3.text)<>0" lines.

What kind of text edit box would contain only numbers and at most, one apostropie?

#44 isn't an apostropie.... it's a comma.  They are looking for number such as 1,000

Anonymous:

Ford351-4V:

I think they forgot to change the name of the edit box in the "if pos(key,edopolm3.text)<>0" lines.

What kind of text edit box would contain only numbers and at most, one apostropie?

#44 isn't an apostropie.... it's a comma.  They are looking for number such as 1,000

#39 is an apostropie.  I do believe you are correct in about the name of the edit box.  Looks like copy paste to me.

Oh, I was holding my ASCII chart upside down! It's a , not '! Oppps, Sorry.

Maurits:

ptomblin:

Here's a WTF: dailywtf.com evidently tries to send email without a valid "HELO". 

May  2 13:17:51 allhats postfix/smtpd[5902]: NOQUEUE: reject: RCPT from unknown[66.232.98.34]: 504 : Helo command rejected: need fully-qualified hostname; from= to= proto=SMTP helo=

Single-element HELO is explicitly allowed by RFC 821, and back-compat'ed by RFC 2821.

I have no problems accepting single element HELO's (well I grumble a little bit), but no mail server I control accepts mail from systems that HELO as "localhost" unless the IP address really is 127.*

That is my first line of spam-filtering and it catches about 50% of the spam that hits my domain

"Also, I didn't know they coded Delphi in Delphi."

Actually, we did. Delphi was written in Delphi using the Visual Component Library (VCL) that every customer could use (and view as source code). For Delphi 1, we were very pround that we could compile our own product in 15 minutes while the C++ took over 2 hours.

Bad code is bad code, even in Object Pascal.

Cheers
-- Richard C Haven
    at Borland for Delphi 1, 2, and a bit of 3, and a long-time (and continuing) user

GoatCheez:

Why did the first guy create more than one of the same function? What the hell? The function is also strewn with WTFs too.... WHAT THE HELL?!?!?!?!?!

Because these are event handlers generated by clicking on the individual controls in the visual designer.  Each method is handeling the key press event for a different control.  This code easily demonstrates that the person understands the tool but doesn't understand software development.  Handeling each event seperatly is the straightfoward (but quite unmaintainable) way of developing software.  I've seen tons of code like in many different visual environemnts and it is pretty clear that those who write code in this way need to find other professions because while they might be able to make programs work, they don't write good software (maintainable, robust, etc.).

This doesn't make me say "WTF".  More like "*sigh* another one of those . . . "  I've just seen this too many times for it to make much of an impression.

Otto:

Now, this is a simple example. The actual code I was looking at was 10k+ lines long, with hundreds of possible states, and each state had not one exit point, oh no, but many possible exit points leading to other states. All the variables these states used were shared by all the other states because of scoping rules, so every variable was equivalent to being global.

That seemed to be the preferred way of coding in UnrealScript... of course I only played around with it for one semester of college, maybe it got less bad if you used it more...

John Bigboote:

Wait, sorry, there's no way that's VB.

It's Delphi VCL,

Otto:

Maurits:

RFC 2821 in turn supersedes RFC 1123 (the mail bits of it, anyway) and reinstates the legality of the RFC 821 behavior:

Actually, looking through RFC 821, I fail to see where it says that domain is optional in the HELO command

<domain> is required, but does not need to be fully-qualified:

HELO <SP> <domain> <CRLF>
...
<domain> ::=  <element> | <element> "." <domain>

Note that the <domain> can consist of a single <element>.

It is rather shocking that Community Server follows RFC 821 and not RFC 2821 though.

Edgar Plonk:

Pascal identifiers are case-blind, aren't they? So that gets the FALSE guy mostly off the hook; it looks
stupid, but it'll compile and it'll do what it ought to at runtime --
unless Delphi diverges from normal Pascal in that respect.



Personally, I enjoy the fact that moron languages like Pascal and VB
are case blind (not to mention Microsoft's filesystems): It gives
stupid people a well-deserved kick in the teeth if they ever try to
venture beyond the apron strings.

In the good old days of Turbo Pascal, there was a compiler setting to make it CAsE sEnsiTiVE.

Edgar Plonk:

Pascal identifiers are case-blind, aren't they? So that gets the FALSE guy mostly off the hook; it looks
stupid, but it'll compile and it'll do what it ought to at runtime --
unless Delphi diverges from normal Pascal in that respect.



Personally, I enjoy the fact that moron languages like Pascal and VB
are case blind (not to mention Microsoft's filesystems): It gives
stupid people a well-deserved kick in the teeth if they ever try to
venture beyond the apron strings. The more arbitrary barriers to entry
there are, the less chance they'll ever bullshit their way into a real
job and generate WTFs for me to waste my time on.

Wow. Talk about useless inanity.



It's as though you confuse case sensitivity with, oh, actual CODE STRUCTURE  or something.



Oh, yeah. Knowing that "false" outta read "false" and not "FALSE" or
"False" is a sure way to identify those who can write clear,
understandable code...



Good quality code starts with layout conventions that are sane,
consistency in writing, comments that define the either the objective
or the data formats, rather than the action itself, etc. And being able
to spell is a plus.  (trying to figure out why (louvre==5) and
($louver==3) can be a recipe for SERIOUS PAIN)



The real WTF here is your comment.

Searching... for... WTFs of Massive Proportions.  I only let out a little fart while reviewing this one. [:^)] I need something that'll make me junk my drawers, seriously. [+o(]

---

Anyone use MOOSE?  I hear it's very versatile.

 

Otto:

The person who wrote it called it a "state machine", which made me kinda want to hit him.

Basically it was like this:
enum possibleStates = {state1, state2, state3, etc};
possibleStates currentState = state1;
while() // infinite loop
{
switch (currentState) {
case state1:
    do some stuff
    currentState = state2;
    break;
case state2:
    do some stuff
    currentState = state3;
    break
case state3:
    do some stuff
    currentState = state1;
    break;
} // end switch
} // end while

Now, this is a simple example....

This is the typical code that one gets when hand coding a parser from a BNF specification.  That you had a co-worker competent enough to get a parser like this written and working is a complement to your co-worker.  I have worked with so many people who cannot understand the rudiments of parser construction that I have mostly given up on writing 'little languages' within 'enterprise'y code.

That being said, I am aware that there are MUCH better ways to code the parser.  The best is if you can use some tools like yacc and bison (in C) or JavaCC (if in Java) and then you can get close to maintaining the specification for the parser rather than the implementation.  If you must hand code use the GoF state pattern in an OO language (an object for every state with a polymorphic funtion that returns the following state).  In C this will result in too many pointer-to-pointer variables (always good for a long debugging session) so break it up into functions:
[pre]
while handleState1();

int handleState1() {
    do some stuff
    while handleState2();
}

int handleState2() {

    do some stuff

    while handleState3();

}



int handleState3() {

    do some stuff
}
[/pre]



This is actually harder to maintain than the infinite loop IMHO since the specification becomes frozen into the structure of the code.  For changes in semantics it is easier to make small changes in.  But watch out for people who "don't get it" and try to make syntactical changes within a single function.

Alex Papadimoulis:

procedure Tfrmobr.Edopolm3KeyPress(Sender: TObject; var Key: Char);

begin

if not (key in [#8,#44,#48..#57]) then key:=#0;

if key=#46 then Key:=#44;

if key=#44 then

   if pos(key,edopolm3.text)<>0 then key:=#0;

end;

if key=#46 the Key := #44;

This line was a waist of time.  #46 would not have made it past the previous line.

Mike:

Edgar Plonk:

Pascal identifiers are case-blind, aren't they? So that gets the FALSE guy mostly off the hook; it looks
stupid, but it'll compile and it'll do what it ought to at runtime --
unless Delphi diverges from normal Pascal in that respect.



Personally, I enjoy the fact that moron languages like Pascal and VB
are case blind (not to mention Microsoft's filesystems): It gives
stupid people a well-deserved kick in the teeth if they ever try to
venture beyond the apron strings.

In the good old days of Turbo Pascal, there was a compiler setting to make it CAsE sEnsiTiVE.

In the good old days of Turbo Pascal noone paid attention to the difference between FALSE, false and False. That wasn't the point of it.

PCBiz:

Alex Papadimoulis:

procedure Tfrmobr.Edopolm3KeyPress(Sender: TObject; var Key: Char);

begin

if not (key in [#8,#44,#48..#57]) then key:=#0;

if key=#46 then Key:=#44;

if key=#44 then

   if pos(key,edopolm3.text)<>0 then key:=#0;

end;

if key=#46 the Key := #44;

This line was a waist of time.  #46 would not have made it past the previous line.

"waist of time".  That maid me chuckle.

#define true false
#define false true
#define FALSE file_not_found