• (nodebb)

    I'd rather live in New York than maintain this code.

    Or... maybe this code over NY... I don't know.

  • (nodebb) in reply to Mr. TA

    Dunno. I've lived in New York (the state), but not in New York (the city). It seemed like a nice enough place.

  • AnonToday (unregistered)

    I think that The problem with the double removal that the first one deletes the found text, removes the found text, and then jumps the search forward by the length of the found text (that isn't there anymore). So, if the search text was repeated in the original content, the search finds and removes the first instance and then skips the search past the second instance.

    How anyone would simply leave that code, when there's clearly a bug, is beyond me. Hang on, no, I have colleagues like that. The attitude is "well, it works, doesn't it?". :-(

  • (nodebb)

     

     

    Do it twice...

  • Edd (unregistered)

    No inline base64 images?

  • Bob (unregistered)

    Doing it twice because the offset might skip some... If content starts with 2 of those, the first pass will remove the first one, and move $offset past the second one... Unfortunately doing it twice does not guarantee they will all be removed, a chain of 5 of those will remove 3 the first time, 1 the second time, and still have 1 left in the end. If only there was a function like str_ireplace to remove them all in one go...

  • fs (unregistered)

    Even without the addition in offset, you might want to run it twice: This way you get nested tags.

  • Code Refactorer (unregistered) in reply to fs

    Yes, done twize to completely remove nested tags of second grade, like:

     

     

  • Ann Onymous (unregistered)

    4.35 weeks per month? So 30.45 days per month?

    I know there is bad date/time handling code, and truly bad date/time handling code, but this? All the yikes.

  • Get with the times (unregistered)

    Obviously should have just used Metric Time! Also, why the use of 4.35 instead of 4.333333333? Ahhh, accounting for leap days! (3.48214...) I guess to do the equivalent it would have to be something like the first user comment shown here: https://www.php.net/manual/en/function.date-diff.php and then manually trimming after the second, space-separated token? There don't seem to be any date rounding-by-biggest-unit functions. As a saving grace, the rounding in the code never rounds up to the next unit ("364 days" never becomes "1 year"), but you'd still have to add half of your unit to the original difference, which is problematic, because half of a year changes, depending on the year. I think I'd be content with their approach for general use where back of the envelope works.

  • Chronomium (unregistered)

    As yes, the good ol' 4.35 weeks in a month, a classic datetime calculation value.

  • (nodebb) in reply to fs

    So it generates code like this?

    <p>&nbsp;<p>&nbsp;</p></p>
  • Brian (unregistered)

    Wait, so they explained during the interview that this system had grown so complex that it required a full-time employee to maintain, yet it was "basically just one PHP file"? And Maxi still took the job? There's your TRWTF right there.

  • Sole Purpose Of Visit (unregistered)

    Not really relevant to this particular WTF, but I sometimes wonder about the tendency of "contractors" to produce web pages programmatically, painstaking element by painstaking element. Apparently the idea of using templates has died a death somewhere along the line.

    Templates might actually be a casualty of the "go to CodeWizrads, do not pass go, copy, paste, rinse, repeat" style of coding. It's incredibly easy to copy loony chunks of code (such as the URL handling nitwittery displayed here). It requires a house-trained gibbon to go as far as looking up a suitable template and adjusting the HTML.

    Thinks to self: might be a good business opportunity for me. How many mangoes does the average house-trained gibbon need for simple PHP programming?

  • (nodebb)

    How long was this site live? Did all this accumulate within one years or less, or did it take multiple yearss?

  • whoops (unregistered) in reply to Get with the times
    • that's 4.348214
  • tbo (unregistered)

    The "date handling" is kind of interesting. Not in that it's good code, just in its requirements. It's taking a time and converting it to a relative time, which is something I don't really see all that often (especially in something old like this), but also... if it's wrong, a little bit? Who cares?

    To me, the funniest part is how they didn't even read the PHP documentation for stripos, so they add an extra space to the start of $content so that they'll never find the needle at the start of the haystack and prematurely exit the loop before replacing anything.

  • Appalled (unregistered)

    Whoever copy/pasted the same chunk of code in dozens of places either never heard of PHP Includes, or was paid by lines of code.

  • (nodebb) in reply to tbo

    I noticed something on June 1 in JIRA. When I went to my "Your Work" page, all the tickets I'd worked on the previous Friday were in the group "In the last month" instead of "In the last week". I guess since it was June, anything in May was a month ago, even if it was just a couple of days earlier.

  • Dave D (unregistered)

    tbo, the reason they add the space is so stripos returns 1 instead of 0 if the needle exists at the start of the haystack, otherwise it would prematurely exit the loop before replacing anything.

  • Dave D (unregistered)

    After reading tbo's comment a few more times, I think he meant exactly the same as what I said.

  • (nodebb)

    This is child's play. TRWTF is a 9.2MB stylesheet that is called in every page, with a timestamp in the href so it is always stale and must be reloaded whenever it is used - in division in every frame on every page. (Yes - FRAMES!)

    Why? So glad you asked: Because we need to make sure that every page on the site needs to have every attribute for every possible object on every page on every site on every network on every continent, and those attributes need to be available in every font in every point size in every possible color scheme for every possible theme palette for every rainbow in every Universe and support every possible edge/border/corner/3D-effect combination for every possible browser on every possible platform at all times -- on a site that does not allow the viewer to change their theme when viewing the site and only uses one font, one size, one color, one corner, and one border type throughout the entire site.

    Again I ask: WHY?? And the answer ways, "Y'know ... just in case.... "

    WebGuy didn't last anywhere near as long as it took to load 3 pages.

    Addendum 2021-06-08 12:03: EDIT: Last part of frist paragraph should read, "... whenever it is used - in every division in every frame..."

  • Loren Pechtel (unregistered)

    The doing it twice bit is even more complex than other posters have identified:

    1. As others have identified, the original says $offset = $pos + 13; instead of the correct $offset = $pos; This will skip over any tag within 13 spaces.

    2. As others have identified, nested tags.

    The first is an easy fix, but the nested tag one is not--doing it twice will remove singly-nested tags, but what if you have a doubly-nested tag? The only way to ensure you actually get every case is to put your stripper inside a loop that tries again after any pass that makes a change.

  • t (unregistered) in reply to Barry Margolin 0

    YouTube filters always annoy me because of this. You filter by upload time and it has e.g. "this week" as an option, but really means "Past 7 days".

  • xtal256 (unregistered) in reply to AnonToday

    How anyone would simply leave that code, when there's clearly a bug, is beyond me. Hang on, no, I have colleagues like that. The attitude is "well, it works, doesn't it?". :-(

    The sad thing is that I probably know of more developers who are like that than not.

  • a guest (unregistered)

    Bad code aside, my personal favourite will have to be 1 years, 2 yearss, 3 yearss.

  • 516052 (unregistered)

    I am kind of disapointed that the code wasn't written reusably. Imagine just how much more of a WTF it would have been to see a well written, reusable, pattern compliant but utterly moronic giant PHP file.

  • Wut (unregistered)

    I like the while ($pos = stripos(...)) loop condition. What does stripos return when it can't find the search string? False. What does it return when it finds the search string at the very beginning? 0. What do those two values have in common? They're both "false" in a boolean context, so if $content starts with the search string, the loop stops prematurely.

    Now, you could fix the problem by just doing while (($pos = stripos(...)) !== false), but that would be slightly too obvious. Instead, this code does $content = " " . $content beforehand, thus ensuring that the search string will never be found at offset 0. Geniouse!

  • Jan (unregistered) in reply to whoops

    Actually it's 4.348125 (exactly). There isn't a leap year every four years.

  • Best Of 2021 (unregistered) in reply to AnonToday

    Yes, the multiple replacement is because each replacement is shortening the string but still incrementing the start position by the length in the old string. This is a classic example of when it's better to iterate backwards. Although in this case I think just not incrementing pos will sort you out.

    Though in this case a simple call to a multiple replacement function delegates the whole problem to the framework.

  • tbo (unregistered) in reply to Dave D

    Indeed. :)

  • (nodebb) in reply to Loren Pechtel

    No it's not the only way. You could use a parser (LALR or even recursive descent should be able to handle it) instead of iterating a stupid regexp.

Leave a comment on “Contractor Management System”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article