• cfreak (unregistered) in reply to mbvlist
    mbvlist:
    Schmalls:

    No the quotes aren't redundant. It is doing the same thing as:

    $x[hostid] . '.' . $x[hostname]
    However, a big WTF is that the array key isn't quoted like so:
    $x['hostid'] . '.' . $x['hostname']
    When left unquoted, PHP first checks to see if there are constants named hostid and hostname and if there are none it emits a notice and uses the string instead.
    It doesn't work like that when in a string AFAIK. You can test it using this code: $array['true'] = 'The Real WTF is PHP syntax.'; $var1 = "$array[true]"; $var2 = $array['true'];

    I think $var1 and $var2 have the same value. Don't ask me why, it is pretty much crap anyway.

    So true. PHP took all the worst parts of Perl, C and more recently Java, blended them together and called it a "language"

    (I'm allowed to say that because I write PHP for a living)

  • cfreak (unregistered) in reply to Ralph
    Ralph:
    More WTF,

    $int = 1; $string1 = "the value of int is $int"; $string2 = 'the value of int is $int';

    $string1 will contain "the value of int is 1", while $string2 is "the value of int is $int" , single quotes are dumb strings, but when double quotes are used the interpreter will look at your string and insert any variables it finds.

    That's a Perlism and it really does make sense: interpolating can be slower, if you know you aren't going to be interpolating a variable it gives you a bit of a performance boost and the added security to know someone can't externally muck with your string. It's also convenient if you need literal $ signs in your string (and in perl more so since it uses other symbols like @ and % for arrays and hashes)

  • Medezark (unregistered)

    I would hate for anyone to have too look at my current code, much less the code I wrote in the period during or immediately after learning a new language.

  • (cs) in reply to Medezark
    Medezark:
    I would hate for anyone to have too look at my current code, much less the code I wrote in the period during or immediately after learning a new language.

    So how are you at working in a team? In order to work effectively, you have to be able to let your peers review your current code.

  • Medezark (unregistered) in reply to pitchingchris
    pitchingchris:
    Medezark:
    I would hate for anyone to have too look at my current code, much less the code I wrote in the period during or immediately after learning a new language.

    So how are you at working in a team? In order to work effectively, you have to be able to let your peers review your current code.

    Teams are so gay. Peer reviews even gayer.

  • (cs) in reply to Medezark
    Medezark:
    pitchingchris:
    Medezark:
    I would hate for anyone to have too look at my current code, much less the code I wrote in the period during or immediately after learning a new language.

    So how are you at working in a team? In order to work effectively, you have to be able to let your peers review your current code.

    Teams are so gay. Peer reviews even gayer.

    With an attitude like that, I really wish you would put some of your code up on here. I'm sure we'd all enjoy it

  • Medezark (unregistered) in reply to Malenfant
    Malenfant:
    Medezark:
    pitchingchris:
    Medezark:
    I would hate for anyone to have too look at my current code, much less the code I wrote in the period during or immediately after learning a new language.

    So how are you at working in a team? In order to work effectively, you have to be able to let your peers review your current code.

    Teams are so gay. Peer reviews even gayer.

    With an attitude like that, I really wish you would put some of your code up on here. I'm sure we'd all enjoy it.

    You are so gay.

  • (cs) in reply to FragFrog
    FragFrog:
    A LOT of crap gets written in PHP because people don't know what they are doing, ... It's just that PHP makes writing bad code so much easier

    PHP == VB ??

  • iusto (unregistered) in reply to JRiddy
    JRiddy:
    BentFranklin:
    Unless your aunt was Grace Hopper.

    Nice reference.

    Wikipedia: "In 1985, the rank of Commodore was renamed Rear Admiral, Lower Half."

    WTF?!?!?

    I suppose we should be grateful it's not "Rear Admirer, Left Half"...

  • (cs) in reply to Anonymous
    Anonymous:
    My favourite:
    <SCRIPT LANGUAGE="QBASIC">IF $BROWSER = "IE" THEN GOTO 50</SCRIPT>
    ...also the single <JAVA> tag that appears for absolutely no reason.
    Well, there's also the random piece of almost-C++, the <FONT STYLE="FORTHRIGHT"> (ok, I shortened it), the , and the chunk of Scheme that's sitting in its own <SCRIPT> tag. Did anyone ever implement a browser which could handle that? (Also, is
    <lang="american espa☃ish"=""></lang="american>
    misencoded, or is it a feature of my browser? Right now, I could believe either.)

    Overall, it brings back so many memories of When the Web Web was Young. Mostly bad ones. My eyes hurt whether I look at the source or the rendered page. (Animated backgrounds? That are mostly the same color as the text? Webrings? A "best viewed in" blurb? Oh my!) If it hadn't been deliberate, it would have been perfect. As it is, it's slightly too clever. Scary too. It really was that bad. Still is in some parts of the 'net.

    (Randall, if you're reading this... the blink tricks didn't work on Safari. More javascript was needed. I suppose that would have fitted in just perfectly with the rest of that monstrous masterpiece...)

  • captain obvious (unregistered) in reply to noway!

    Former statement's correct, latter is not. The dot in the middle is part of the string.

    Nevertheless, this is bad coding practice, as a) it is unreadable, and b) the array key is parsed as a constant. If someone created a constant named "hostname", the code would most likely fail.

    Finally, who the fuck names a variable $ainstall and all in lowercase?

  • 50% Opacity (unregistered)
    foreach ($aservers as $x) {
       $type = $ainstall["$x[hostid].$x[hostname]"];
       if (! isset($type)) $type = 'null';
       $avalues[$type]++;
    }
    

    Shouldn't that be:

    foreach ($aservers as $x) {
       $type = 'null';
       if (isset($ainstall["$x[hostid].$x[hostname]"])) {
          $type = $ainstall["$x[hostid].$x[hostname]"];
       }
       $avalues[$type]++;
    }
    

    In the proposed code, $type is clearly being set, but it may or may not be empty().

  • Gaylord (unregistered) in reply to Medezark
    Medezark:
    Malenfant:
    Medezark:
    Teams are so gay. Peer reviews even gayer.
    With an attitude like that, I really wish you would put some of your code up on here. I'm sure we'd all enjoy it.
    You are so gay.
    Why honey, you looking for some?
  • 50% Opacity (unregistered) in reply to captain obvious

    And to everybody who still didn't get the "$var[name]" problem:

    It's a special case for the parser. PHP does NOT see a constant called "name" here.

    $var['name'] == "$var[name]" == "{$var['name']}";
    $var['name']['name2'] != "$var[name][name2]";
    

    PHP interprets one dimension of array keys in strings with no quotes. Two or more need to be put in curlies {} and quoted as usual.

    I'd post a link to the manual, but apparently that makes me a spammer. Look for "string parsing" on php.net yourself.

  • Mones Adwan (unregistered)

    I spent more than five years in teaching and developing using PHP and MYSQL. And I feel that I have a right to say that the most thing I hate in that domain is spending most of the time in discussing the code it self rather than what the code could do.

  • chunder thunder (unregistered) in reply to Rocketeer
    Rocketeer:
    I enjoyed reading that code - it was like a horror story for programmers :-)
       $hostid    = $aservers[$i][hostid];
       $hostname  = $aservers[$i][hostname];
       $systemkey = $hostid . "." . $hostname;
    

    It started off with a little light foreboding - just as we all know "It was a dark and stormy night..." is going to lead to trouble, so does gratuitous variable creation.

    If you're only going to use the variables once, I agree... though I think in some cases it can improve code readability. This is especially true when either you use the same datum more than once or the array lookup is deep. In the former case, it saves you trying to figure out if two long array dereference sequences are actually identical or just similar.

    Of course, since it's essentially a form of code self-documentation, it's subject to the usual worries about keeping documentation in sync with the actual code...

  • (cs) in reply to 50% Opacity
    $type = 'null'; if (isset($ainstall["$x[hostid].$x[hostname]"])) { $type = $ainstall["$x[hostid].$x[hostname]"];
    The drawback here is that you have to hope and pray that the second $ainstall line matches the first $ainstall line exactly. For short lines that can be confirmed visually; for lines as long as this I'd rather do it once and cope with the results. Even if they match today, they may not match after somebody takes a text editor to your source file.
  • 50% Opacity (unregistered) in reply to AndyCanfield
    AndyCanfield:
    $type = 'null'; if (isset($ainstall["$x[hostid].$x[hostname]"])) { $type = $ainstall["$x[hostid].$x[hostname]"];
    The drawback here is that you have to hope and pray that the second $ainstall line matches the first $ainstall line exactly. For short lines that can be confirmed visually; for lines as long as this I'd rather do it once and cope with the results. Even if they match today, they may not match after somebody takes a text editor to your source file.

    You could, you know, check. The point is though, that the original version does this:

    1. Create variable $type and assign it a value which may or may not exist, which may throw a warning.
    2. Check if variable $type isset, which it definitely always is, because it was declared on the line before.
    3. If $type is not set (never the case), assign it the default value 'null'.

    What I'm proposing is:

    1. Initialize variable $type to default value 'null'.
    2. Check if the value I actually want is available.
    3. If it is, assign value I actually want to $type.

    No chances of throwing an error and no unused code branches. The original is simply nonsense. If you're paranoid about mistyping the $ainstall variable, do this:

    $type = 'null';
    $key = "$x[hostid].$x[hostname]";
    if (isset($ainstall[$key])) { 
       $type = $ainstall[$key];
    }
    
  • 50% Opacity (unregistered) in reply to 50% Opacity
    50% Opacity:
    2. Check if variable $type isset, which it definitely always is, because it was declared on the line before.

    Okay, sorry, scratch that part. !isset($type) is true if $type === null. What still holds true is that you'll get a warning for a missing array key in step one. So instead of getting a warning and dealing with it later I'm proposing a warning-less way, which should always be preferred.

  • (cs)

    So the WTF is what, that instead of hiring a trained programmer to develop the tool, they had some untrained guy who had simply read a "Learn ${Some_Language} in 21 Days" book do it? I'm curious what these managers think we are doing in the 4 years we spend getting a degree in college if they think programming can be learned in 21 days...

    I wonder if I bought a "Learn People Management in 21 Days" book, would upper management would let me become a vice president of something?

  • burpy (unregistered) in reply to dunawayc
    dunawayc:
    FragFrog:
    A LOT of crap gets written in PHP because people don't know what they are doing, ... It's just that PHP makes writing bad code so much easier

    PHP == VB ??

    Funny that you mention it. How come we never see WTFs written in real programming languages??? Always in Personal Home Page or visual "look look, I made a window with a textbox" basic!

  • Jan (unregistered) in reply to EmperorOfCanada

    Or maybe he was a dumbass.

    He was not a dumbass. This was a clever solution from someone who has obviously no programming experience whatsoever.

    The real WTF is not the programmer fucking up, but management allowing such a system to grow over the years without ANY feedback from real developers.

    Programming is hard; allowing someone who is not a programmer to build a large and obviously important application is asking for trouble. Nobody does these things right the first time without some guidance.

  • roger (unregistered) in reply to Jan
    Jan:
    > Or maybe he was a dumbass.

    He was not a dumbass. This was a clever solution from someone who has obviously no programming experience whatsoever.

    The real WTF is not the programmer fucking up, but management allowing such a system to grow over the years without ANY feedback from real developers.

    Programming is hard; allowing someone who is not a programmer to build a large and obviously important application is asking for trouble. Nobody does these things right the first time without some guidance.

    Come one, we all know a computer guy is a computer guy. There's no real difference between a programmer, a dba and the guy who changes your keyboard when it's broken...

  • (cs)

    So the guy had an idea about automating the most dumbass tasks and have them online. He hacks a website that does exactly that. Then mister smartass shows up, takes a look at the code and sends it to thedailywtf. "OMG! Look, he stupid! He shouldn't be doing php!" But that's not all. Mr smartass shows how it should be done! Only he doesn't realize his code sucks too.

    Now that's a wtf.

  • The Troll (unregistered)

    On some whim, I've always avoided PHP. Looking at all the code on this issue, I can see why. TRWTF really is the language, this time. The code from the "experienced" guy look almost as bad as the code from the newbie. Laughing at code from a newbie is really not cool.

    CONSEQUAT: There will be

  • winstein (unregistered) in reply to 50% Opacity

    I see these kinds of examples posted a lot in discussions regarding php, and Ive never really understood why.

    who cares? perfect logical inconsistency is a ridiculous goal in any language, and the advantages of php hugely outweigh the occasional linguistic oddity that no decent programmer ever has a problem with anyway because they just dont write code that looks like:

    if($var['name']['name2'] != "$var[name][name2]")

    its is inane to pretend that the existence of such linguistic oddities are sufficient in themselves to render a language good or bad.

  • Anonymous (unregistered) in reply to Mones Adwan
    Mones Adwan:
    I spent more than five years in teaching and developing using PHP and MYSQL. And I feel that I have a right to say that the most thing I hate in that domain is spending most of the time in discussing the code it self rather than what the code could do.
    Then why are you here? Quit discussing and get coding if that's how you feel.
  • Stuart (unregistered)

    Hello, I'm Stuart. I'd like to clarify some things:

    Jim had a great idea, and his website is still in use today - now that it's cleaned up, we can trust the data in it, the pages load within a minute, and it's available for more than a couple of hours a day. It saves all the sysadmins huge amounts of time.

    We have other websites developed by sysadmins who still have their jobs. The difference is they knew when to let go - they handed over their babies to the development team for ongoing maintenance and they got back to being good sysadmins rather than poor programmers.

    Jim had several years to learn proper development practices, but he believed his tinkering was good enough programming. Nobody cared to look under the hook and challenge him about it, so he didn't bother learning any more. Nobody worried about this until things started coming unstuck. The code you see here is not a beginner's first attempts, it's from someone "with several years development experience".

    Much of Jim's code is what you'd expect from a non-programmer, which is not a WTF in itself, but this snippet is such a complicated and convoluted way of doing a task that I couldn't work out why he'd ever choose to do it that way.

    The example code is just there to show what Jim's code is trying to do, but in a concise fashion, so you can see what $aservers, $ainstall and $avalues mean. The code in production does a COUNT at the database instead. I apologise for the isset() rather than array_key_exists(), it's a Perlism taken over to PHP.

  • TiS (unregistered) in reply to AndyCanfield
    AndyCanfield:
    $type = 'null'; if (isset($ainstall["$x[hostid].$x[hostname]"])) { $type = $ainstall["$x[hostid].$x[hostname]"];
    The drawback here is that you have to hope and pray that the second $ainstall line matches the first $ainstall line exactly. For short lines that can be confirmed visually; for lines as long as this I'd rather do it once and cope with the results. Even if they match today, they may not match after somebody takes a text editor to your source file.

    Well, most modern editors have functions like copy-paste.

    It clearly could be better to do it once, but as Andy said, this code throws a warning. To be exact:

    Notice: Undefined index: t.t in wtf.php on line 9

    if the index does not exists. Ofc, maybe it always exists, and this discussion is pointless. But in most cases like this one, it MAY not exist.

    Then, you can say that the notice error is not an error as-is and we can deal with it. In many cases you're right, but in a case of debugging and looking through logs the avalanche of notices can be overwhelming. And sometimes there's no good way of debug. I'm currently working with heavily AJAXed and framed spaghetti code, the only place I can use to debug are sometimes logs. Two pages of notices for one request can be a little bit disappointing, not to say it's hard to find something useful in there.

  • Ozz (unregistered) in reply to ZP
    ZP:
    You completely missed the whole.
    That's what she said...
  • Zach (unregistered) in reply to MyKey_

    LOL @ xkcd!

  • Fedaykin (unregistered) in reply to Anon Ymous
    Anon Ymous:
    The_Assimilator:
    Jim aggressively fought off all attempts at transitioning the application the development team so, during a round of cost cutting, Jim was made redundant.

    PHP Parse error: parse error: supplied sentence does not contain valid grammar in C:\Inetpub\wwwroot\tdwtf\Articles\PHP-has-an-eval-function-like-perl.aspx on line 5

    There's nothing wrong with the grammar of that sentence. "Fight off" is a phrasal verb -- it has a different meaning than "fight". (Or are you whining about the use of the passive voice?)

    That sentence is gibberish. Luckily, you are familiar with the context of the sentence so you are able to understand it and your brain doesn't see the error. The part your brain is unjumbling is easier to see as broken when it's outside the context of the sentence:

    "transitioning the application the development team so"

    Also, it has a nasty comma splice.

    What the author meant to write:

    Jim aggressively fought off all attempts at transitioning the application to the development team. So, during a round of cost cutting, Jim was made redundant.
  • Jay (unregistered) in reply to nwbrown
    nwbrown:
    So the WTF is what, that instead of hiring a trained programmer to develop the tool, they had some untrained guy who had simply read a "Learn ${Some_Language} in 21 Days" book do it? I'm curious what these managers think we are doing in the 4 years we spend getting a degree in college if they think programming can be learned in 21 days...

    I wonder if I bought a "Learn People Management in 21 Days" book, would upper management would let me become a vice president of something?

    I just read "Learn Open Heart Surgery in 21 Days". (I skipped a couple of chapters because all that stuff about blood was too gross.) Now I'm going to apply for a job as a surgeon.

  • Fedaykin (unregistered)

    In my current job I work in a development group for a large organization with many offices that often have amateur applications crop up in that we take over and fix when it becomes apparent they are useful on a larger scale.

    If you were able to refactor this application and make it work, then it was a damn fine amateur effort and certainly not a WTF.

    If I could share some of the code from the applications I've taken over (and had to rewrite from the step of requirements gathering), THEN you would know the true meaning of WTF.

  • Jay (unregistered)

    Or better yet ... I think I'm going to call the publisher of these "Learn ... in 21 Days" books and tell them that I just read "Learn How to Write 'Learn in 21 Days' Books in 21 Days" and ask them if they'll give me a book contract with a big advance.

  • (cs) in reply to EmperorOfCanada
    EmperorOfCanada:
    Maybe he had tonnes of Lisp/AI experience and was planning on building a self coding dynamic intelligent system? Or maybe he was a dumbass.
    Or maybe he was a sysadmin with no programming experience who fulfilled his original aim in a short amount of time?
  • (cs) in reply to TiS
    TiS:
    AndyCanfield:
    Even if they match today, they may not match after somebody takes a text editor to your source file.

    Well, most modern editors have functions like copy-paste.

    I'll let that stand as a testament to ignorance.

  • Peter (unregistered)

    http://www.ietf.org/rfc/rfc1760.txt

    The S/KEY system is designed to facilitate this manual entry without impeding automatic methods. The one-time password is therefore converted to, and accepted as, a sequence of six short (1 to 4 letter) English words. Each word is chosen from a dictionary of 2048 words;

    Dictionary for Converting Between S/KEY 6-Word and Binary Formats

    { "A", "ABE", "ACE", ....."YELL", "YOGA", "YOKE" };

  • Peter (unregistered) in reply to Peter

    Ooops - I put my comment in the wrong thread.

  • (cs) in reply to rfsmit
    rfsmit:
    TiS:
    AndyCanfield:
    Even if they match today, they may not match after somebody takes a text editor to your source file.

    Well, most modern editors have functions like copy-paste.

    I'll let that stand as a testament to ignorance.

    That's why you have tests on application (like, unit tests and so). You have them, right? Ok, jokes over. You have in perfect world, but... If you want 'editor-safer' approach you can do it like that

    Ah, 50% Opacity already wrote this

    $key = "$x[hostid].$x[hostname]";
    if (isset($ainstall[$key]))
      $type = $ainstall[$key];
    (in fact I write like that in more complex keys I have to use more than once)

    or, if you preffer dirty approach

    $key = "$x[hostid].$x[hostname]";
    $type = isset($ainstall[$key])?$ainstall[$key]:'null';
    But the overall approach should always be - FIRST test if something exists, THEN use it. It's better practice, other languages aren't as permissive as PHP.
  • (cs) in reply to Mones Adwan

    My word, the parallels of "PHP has an eval function like perl" here is unprecidented since we are needing to recode a number of 'systems' that had evolved just like this example. The fact that the guy who did it to us is also called Jim is spooky at best. Is it possible to discriminate against network admins that are named Jim?

  • FoolishOwl (unregistered)

    I keep reading posts about sysadmins who don't know how to program. This puzzles me, given all the programming courses I'm taking in order to qualify as a sysadmin.

  • Ouch! (unregistered) in reply to FoolishOwl
    FoolishOwl:
    I keep reading posts about sysadmins who don't know how to program. This puzzles me, given all the programming courses I'm taking in order to qualify as a sysadmin.
    Maybe it used to be different and they included programming courses in the curriculum as a reaction to all those WTFs?
  • Optimus Dime (unregistered) in reply to Schmalls
    Schmalls:
    noway!:
    FragFrog:
    And it keeps saddening me to see things like this:

    $type = $ainstall["$x[hostid].$x[hostname]"];

    Guess what you're doing? That's quite right: in your bright, shiny example you are letting PHP eval that string, the very same principle you're bashing the original writer for.

    That's variable expansion, not code evaluation. Although, i think the quotes are redundant... right?

    No the quotes aren't redundant. It is doing the same thing as:

    $x[hostid] . '.' . $x[hostname]
    However, a big WTF is that the array key isn't quoted like so:
    $x['hostid'] . '.' . $x['hostname']
    When left unquoted, PHP first checks to see if there are constants named hostid and hostname and if there are none it emits a notice and uses the string instead.
    And this is why PHP is retarded.

    Arcane parsing rules are TRWFT.

  • (cs) in reply to FragFrog
    FragFrog:
    And it keeps saddening me to see things like this:

    $type = $ainstall["$x[hostid].$x[hostname]"];

    Guess what you're doing? That's quite right: in your bright, shiny example you are letting PHP eval that string, the very same principle you're bashing the original writer for.

    Are you being serious? It gets interpolated, not eval'ed. Big difference.

  • anonymous (unregistered)

    There is a massive difference between copying the syntax from a book and learning a language.

    But yeah, you can write bad code in any language if you try hard enough, try this beauty from the our application that I found just now in our mature, widely used java app (This is not a unique example).

    StringBuffer sqlStmtStr = new StringBuffer(); .... sqlStmtStr .append("AND f.name = " + nameStr + " " ); ....

    ahhh, what a day I have infront of me.

  • Jeh-fuh-fuh (unregistered) in reply to FragFrog
    FragFrog:
    And it keeps saddening me to see things like this:

    $type = $ainstall["$x[hostid].$x[hostname]"];

    Guess what you're doing? That's quite right: in your bright, shiny example you are letting PHP eval that string, the very same principle you're bashing the original writer for.

    Erm, no you're not - while it's not how I would have done it, is essentially doing: 1) resolve var values 2) concatenate 3) do a hashmap lookup. There's no eval involved.
    A LOT of crap gets written in PHP because people don't know what they are doing, but to write truely good PHP code is both possible as well as just as hard as writing good code in any other language. It's just that PHP makes writing bad code so much easier :]
    Actually no, you're wrong. It's not possible to write truly good PHP code.
  • Jeh-fuh-fuh (unregistered) in reply to Airhead
    Airhead:
    Severity One:
    FragFrog:
    ...but to write truely good PHP code is both possible as well as just as hard as writing good code in any other language.
    I would say it's a lot harder. :)
    So, you don't know PHP? ;)
    I daresay the problem is that he does know it.
  • Jeh-fuh-fuh (unregistered) in reply to Dan
    Dan:
    Since it would have been wasteful to rewrite it from scratch, there are still vestiges of Jim in there

    In my experience, it's sometimes better to learn from the first attempt, then scrap it entirely and rewrite it. You often come up with better organization and improve maintainability to the nth degree that way. I've been involved in too many projects where "we don't have time to really fix it, so just fix the problem" and the "just fix it" only made the code harder to work with and often introduced even more problems.

    But scrapping the code and rewriting it /never/ has problems, right? I mean - it's always flawless out the gate... ;)

Leave a comment on “"PHP has an eval function like perl"”

Log In or post as a guest

Replying to comment #288991:

« Return to Article