• Slater (unregistered) in reply to GF
    GF:
    Franz Kafka:
    DeLos:
    Slater:
    God, I hate Hungarian Notation. What a horrible, horrible crutch for a young programmer to take up. It's as bad a smoking, really.

    I disagree. It is quite useful when you are looking at other people's code. It can help guide you into the other person's thought process and figure out what variable do.

    I redisagree. hungarian notation as it's used is worthless and can be an impediment if datatypes have been changed without updating variable names. Proper hungarian notation means decorating names with app-level info about what the variable represents, not the datatype.

    Ah, the old "what if the data type changes" argument. (snip)

    wParam, lParam anyone? It was exactly this phenomenon in a large project that convinced me to finally start the long and painful process of "unlearning" Hungarian Notation.

    It's not that Hungarian Notation isn't useful in some cases it's that 90% developers who use it can't function without it and use it as a crutch in place of thoughtful variable naming. If you're naming your variables objCDO you are hopelessly, hopelessly lost, and your only course of action is to give up Hungarian Notation completely.

  • Mexi-Fry (unregistered)

    OMFG OMFG OMFG OMFG OMFG .... DAMN DAMN FUNNY!!!

    Sadly... I have seen the like of it... done by perl guys who are mainly LAMP admins but not really programmers... so they do the web pages the same way that they do their bash scripts.

  • Jens (unregistered)
    Comment held for moderation.
  • G. Henkel-Wallace (unregistered)

    That's brain-damaged. I recommend upgrading the whole configuration to Linux -- I hear it's the latest thing. Then for legacy compatibility you should run virtualization software -- that's really the latest thing -- so you can run Windows under virtualization, and then run that script under Linux; the script can still generate an ASP file which can be loaded into the virtualized process and....the rest of the exercise is left as an exhausting exercise for the reader.

  • /dev/null (unregistered) in reply to notromda
    notromda:
    Nevermind the glaring WTF - this is a huge security hole! With a hand crafted form one could write an entire asp script to do whatever you want on the web server!

    Indeed, I was had to pay a visit to HQ for contracting company worked for. They had assigned this old, chubby, deluded chap who thought that instead of sending data(csv,xml,etc) to some service, you send python code which is then execute. I was too polite to assault him there and then, I merely stated that security for such and idea is extremely risky and application internals would need to be exposed. It was pure madness...I started calling him Mince, it was Vince, but Mince sounded appropriate.

  • David (unregistered)

    The real WTF here is that anyone still uses Perl.

  • asifyoucare (unregistered) in reply to LukeG
    Comment held for moderation.
  • asifyoucare (unregistered)

    The real WTF is that you're involved with the issue. They wrote it - they support it. I'm sick of incompetent developers handing off their shit to someone else.

  • brazzy (cs) in reply to GF

    [quote user="GF"] Ah, the old "what if the data type changes" argument. You know, in 15 years of professional programming, I think I've seen that maybe 5 or 10 times. The benefits of Hungarian notation 'as it's used' far outweigh the supposed 'risks', especially when you're trying to scan through unfamiliar code.[quote] What are the benefits of encoding the type in the variable name? In statically typed languages, there are none, plain and simple. The type is stated when the variable is declared, which should never be far from where it's used and is always readily available in any IDE worth using.

    And dynamically typed languages? Well, if you need to know the type of each variable at all times, use a statically typed language, that's their point.

    [quote]Here's a secret - it doesn't even matter what the prefixes are, as long as they're consistent with each other.[/quote] Wrong. What matters, the ONLY thing that matters, is that the variable names help understanding the program's logic. Type prefixes don't. At best, they're superfluous.

  • dkf (unregistered) in reply to Jens
    Comment held for moderation.
  • dkf (unregistered) in reply to brazzy
    brazzy:
    What are the benefits of encoding the type in the variable name?
    It depends on what you're encoding. Encoding the fact that it's a 32-bit wide integer is probably not a good idea as the info is trivial to discover, but saying that that integer represents a packed coordinate (or whatever) is very useful, especially as even the smartest IDE is unlikely to be able to guess the intention of it for you. And guess what? If you actually go and read about it, you'll find that "Apps Hungarian" is sensible and does that sort of thing. ("Systems Hungarian" is the disaster, perpetrated by idiots who just don't get the purpose of what Charles Simonyi invented it for.)
  • Hinek (unregistered)

    Reminds me of an PHP web application I saw as an intern some years ago. It didn't store the users in a DB or flat file. It saved them to another PHP script as a new case block into an existing switch block. All "secure" PHP scripts of the application had to include said script ...

  • 28% Genius (unregistered) in reply to Rich
    Rich:
    ... This is a specific case of the general "trust all inputs from client, what could possibly go wrong" of the script. ....

    Nothing. All input is checked with Javascript in the browser.

    <duck>
  • yhamade (unregistered)

    That's ridiculous...

    On a side note I think I'm the idiot that wrote that port of Matt Wright's FormMail script that used BLAT... I hope nobody is still using that abomination.

  • real_aardvark (cs) in reply to use Table::Wooden qw( :VBScript)
    use Table::Wooden qw( :VBScript):
    real_aardvark:
    So, tell me again. What's wrong with this little snippet? And how would you make a significant improvement?

    Hmm...

    • You might use the CGI module, as it's not 1996 any more

    • As a result, you could then avoid using that antediluvian hairball of code to interpret the client request

    • You could maintain application state on the server, rather than passing lots of hidden form fields, many of which need likely never go near the client, through multiple client requests

    • You could properly check and sanitize inputs, rather than allowing the script to be used as a spam gateway for the rest of the world

    • You might want to use e.g. Mime::Lite to send the mail message. You already have SMTP running to make CDONTS work, so this will work. However, unlike CDONTS, you don't need SMTP running on the same box as IIS

    • You could display whatever you wanted to display to the user as a result of the submission, rather than having to redirect them twice

    • You might want to limit the number of programming languages and technologies involved in this trivial task beyond one

    • You would perhaps try to avoid creation of an unnecessary file to do something that is completely unnecessary

    • Even if you did do that, for some extraordinary reason, you might want to avoid writing to a "temp" file with the same name each time, leading to concurrency issues

    • Even if you were dumb enough to do that, you might want to avoid client-side redirects to send the user to the temp file, although this would be the very least of your worries

    Apart from that it's a pretty good solution though.

    Well, good God, I'd never dream of writing something like this from scratch. It is, however, a mere twenty five lines of crud, all of which is easily understandable; which hardly makes it a "hairball." Whether or not it uses CGI doesn't seem that big a deal.

    Yes, I'd avoid adding ASP into the mix. (Or, more generally, using it at all.) But I'm making no assumptions about the business "logic" in the organisation, which for all I know has a PHB architect insisting that all mail messages go through ASP.

    Yes, I'd avoid hard-coding, particularly for the silly temporary file. I assume, since this little script has been sitting around for a while, that this design mis-feature hasn't caused significant problems up to the point where the server is moved. But, yes, it's dumb.

    Yes, I'd use Mime::Lite (or something). However, it's not a part of the standard distribution. Extrapolating from the presumption that this is an ASP shop, I suspect the developers would have had exactly the same problems that I've had on Windows systems, trying to get some simple piece of functionality installed.

    I agree: you are correct on every point.

    However, in the real world, stuff like this seeps into production. Fine, as long as

    (a) it works (b) it's intelligible (and therefore maintainable) (c) it's safe (and here I agree with you about the lack of sanitized input -- a WTF that is both common and strangely unremarked in previous posts on this thread) (d) it has a clear enough interface to be replaced in situ when the need arises.

    This really isn't a WTF. It's just your ordinary, bog-standard, garden-variety piece of mental compost that can be found in practically any system, anywhere, and is merely the consequence of allowing idiots to specify the design of a system, idiots to implement the details of a system, and idiots to maintain the system for the next ten years.

  • foo (unregistered) in reply to GF
    GF:
    Franz Kafka:
    DeLos:
    Slater:
    God, I hate Hungarian Notation. What a horrible, horrible crutch for a young programmer to take up. It's as bad a smoking, really.

    I disagree. It is quite useful when you are looking at other people's code. It can help guide you into the other person's thought process and figure out what variable do.

    I redisagree. hungarian notation as it's used is worthless and can be an impediment if datatypes have been changed without updating variable names. Proper hungarian notation means decorating names with app-level info about what the variable represents, not the datatype.

    Ah, the old "what if the data type changes" argument. You know, in 15 years of professional programming, I think I've seen that maybe 5 or 10 times. The benefits of Hungarian notation 'as it's used' far outweigh the supposed 'risks', especially when you're trying to scan through unfamiliar code.

    Here's a secret - it doesn't even matter what the prefixes are, as long as they're consistent with each other. Though I guess if you're tripped up by Hungarian, that concept may be too much..

    captcha: abico, usage: abico-ld on this chilly night.

    Really? I was just working on a driver port from a 32-bit to a 64-bit system. The guy who started it used Hungarian and the names were wrong all through the driver. For example, the old 32-bit code assumed 8-bit IDs, so he used cId as the (char) variable name. The new driver needed 64-bit IDs.

    captcha: damnum

  • JohnFx (unregistered) in reply to dtfinch
    dtfinch:
    Around early 2001, at my first programming job out of high school, I wrote my own SMTP queue in VB using winsock, and a COM control for adding mails to the queue, for use in a website I was building in ASP. After I got it all working well, and showed it off to my coworkers, one of them asked, "Why didn't you just use CDONTS?"

    How would using CDONTS teach you anything about socket programming? Especially if you were right of school these types of efforts aren't a total waste of time if they teach you the underpinnings of how a system works. Now you now (roughly) how CDONTS works and will be better at understanding why it sometimes doesn't.

  • use Table::Wooden qw( :VBScript) (unregistered) in reply to real_aardvark
    Comment held for moderation.
  • hex (unregistered) in reply to GF
    Comment held for moderation.
  • mind (unregistered)

    ooh, is this that newfangled 'polyglot programming' i've been hearing about?

  • DaveK (cs) in reply to GF
    GF:
    Franz Kafka:
    DeLos:
    Slater:
    God, I hate Hungarian Notation. What a horrible, horrible crutch for a young programmer to take up. It's as bad a smoking, really.

    I disagree. It is quite useful when you are looking at other people's code. It can help guide you into the other person's thought process and figure out what variable do.

    I redisagree. hungarian notation as it's used is worthless and can be an impediment if datatypes have been changed without updating variable names. Proper hungarian notation means decorating names with app-level info about what the variable represents, not the datatype.

    Ah, the old "what if the data type changes" argument. You know, in 15 years of professional programming, I think I've seen that maybe 5 or 10 times. The benefits of Hungarian notation 'as it's used' far outweigh the supposed 'risks', especially when you're trying to scan through unfamiliar code.

    I have just one word for you, and it's a DWORD:

    wParam.

    GF:
    Here's a secret - it doesn't even matter what the prefixes are, as long as they're consistent with each other.

    They aren't.

  • DaveK (cs)

    You know, I think I can explain how this came about. There's one commented line that provides a vital clue:

    # $email_message = "$answ";
    
    I can almost see the missing comment that should have gone there...
    # $email_message = "$answ";
    # Why doesn't this work?
    
    .. and I can imagine an earlier stage of the script's evolution ..
    $email_message = "$answ";
    # Doesn't seem to work, try setting it again
    $email_message = "$answ";
    # Try to set it again just in case
    $email_message = "$answ";
    # Damn... still doesn't work.  Will have to
    # try something else.  Ok, here we go ...
    $message = 'mailer_d_alt.asp';
    
    Yep. It's one of those variables where you go and set a new value and it just doesn't stick, no matter what you do. So the coder must have thought "Well, if I can't set it now, I'll try moving the set later and see if it works better then. Later. Much later ....", and you can't get much later than by not even setting it until you're serving up a whole new page....
  • real_aardvark (cs) in reply to hex
    hex:
    Ah, the oldest fallacy in the book. Bad programmers can write bad code in any language. If you've never seen good Perl, you've been working with the wrong people.

    On the other hand, PHP is training wheels without the bike. Don't taint Perl with that brush.

    Not quite the oldest fallacy in the book (and I hope you're not talking about the Koran, otherwise I'm gonna have to chop you off at both wrists, the neck, and possibly several other places).

    The oldest fallacy in the book is the statement that "bad programmers can write bad code in any language." Whilst an undeniably sound philosophical concept -- indeed, almost a syllogism -- it breaks down in practice. For instance, I'd love to see a bad programmer's attempt to code in Brainf*ck. Or even in APL. Actually, you could even pick any flavour of Lisp you like, and I doubt you'll find a bad programmer who is good/bad enough to get past the interpreter.

    Some languages, and for perfectly understandable reasons, encourage bad programmers to write bad code. PHP is sloppy enough to be one of them (although it has its uses). Perl, I'm afraid, is another one.

    As God is my witness, I should know. I'm a part-time Perl programmer. Lord, forgive me, because I can't quite remember where I sinned two weeks ago ...

  • Tiago Peczenyj (unregistered)

    Wow... this script isn't Thread Safe o_O

  • Ken (unregistered)

    "It depends on what you're encoding. Encoding the fact that it's a 32-bit wide integer is probably not a good idea as the info is trivial to discover, but saying that that integer represents a packed coordinate (or whatever) is very useful, especially as even the smartest IDE is unlikely to be able to guess the intention of it for you. And guess what? If you actually go and read about it, you'll find that "Apps Hungarian" is sensible and does that sort of thing. ("Systems Hungarian" is the disaster, perpetrated by idiots who just don't get the purpose of what Charles Simonyi invented it for.) "

    One thing I like about C++... if you wanted to use an int as a packed coordinate (or whatever) you could define a class with a single int member variable, put in member functions to manipulate it, and then use the class everywhere that special interpretation is called for, and the compiler will generally (a) just put the int member variable itself in storage (and nothing else) for every instance and (b) automatically inline any functions that are small enough for it to make sense to. So at the machine level, you're still just handling plain ints, but at the source level, they're a different kind of value and you can't just willy-nilly accidently intermix them with regular ints.

  • ClaudeSuck.de (unregistered) in reply to Congo
    Congo:
    J:
    Good variable names==good programming practice, regardless of what notation you prefer. Hungarian requires you to specify your data type, but people who choose good variable names with it will choose good variable names without it (same with bad). While I'd rather dig through bad code with Hungarian than bad code without, Hungarian doesn't make code worse.

    I agree always us i, j, k for integers and a$ through g$ for strings.

    I actually use I, J, K because it's Hungarian

  • Hognoxious (unregistered) in reply to real_aardvark
    real_aardvark:
    The oldest fallacy in the book is the statement that "bad programmers can write bad code in any language." Whilst an undeniably sound philosophical concept -- indeed, almost a syllogism
    Well, apart from needing another premise and a conclusion ...
  • TheHun (unregistered) in reply to magetoo

    Holy code injection vulnerability batman.

  • real_aardvark (cs) in reply to Hognoxious
    Hognoxious:
    real_aardvark:
    The oldest fallacy in the book is the statement that "bad programmers can write bad code in any language." Whilst an undeniably sound philosophical concept -- indeed, almost a syllogism
    Well, apart from needing another premise and a conclusion ...
    I'd argue that the existence of bad programmers is the minor term; the availability of "any language" is the major term, or predicate, if you will; and the phrase "can write bad code" is the conclusion.

    Granted, not in a conventional order; and I'm sure there's a better logical phrase for it. However, for the purpose of conversation rather than for the creation of a philosophical treatise, I'd imagine that "almost a syllogism" will do nicely.

    Good on you for completely evading the actual point of what I was saying, though. TDWTF would be a sad place if we didn't have at least one cretin a week repeating the mantra that "bad programmers can write bad code in any language," as if that statement had any bearing on the price of fish, the buttering of parsnips, or the WTF in question.

  • kmyng (unregistered)
    Comment held for moderation.
  • soso (unregistered)
    Comment held for moderation.
  • soso (unregistered)
    Comment held for moderation.
  • ���� (unregistered)
    Comment held for moderation.
  • �Хå����å� (unregistered)
    Comment held for moderation.
  • いち (unregistered)
    Comment held for moderation.
  • ����Ʒ (unregistered)
    Comment held for moderation.
  • �������� (unregistered)
    Comment held for moderation.
  • ��μ��� (unregistered)
    Comment held for moderation.
  • dfdsfsd (unregistered)
    Comment held for moderation.
  • ����¡�� (unregistered)
    Comment held for moderation.
  • dfdsfsd (unregistered)
    Comment held for moderation.
  • dfdsfsd (unregistered)
    Comment held for moderation.
  • dfdsfsd (unregistered)
    Comment held for moderation.
  • ��ɽ�豸 (unregistered)
    Comment held for moderation.
  • dfdsfsd (unregistered)
    Comment held for moderation.
  • Google (unregistered)
    Comment held for moderation.
  • dfdsfsd (unregistered)
    Comment held for moderation.
  • �������� (unregistered)
    Comment held for moderation.
  • dfdsfsd (unregistered)
    Comment held for moderation.
  • �Ϻ����� (unregistered)
    Comment held for moderation.

Leave a comment on “The One Script”

Log In or post as a guest

Replying to comment #:

« Return to Article