• Prime Mover (unregistered)

    Capital HTML tags, yep, definitely a hanging offence.

    In other news, a Fortran program I've been given to maintain has some of the routine names written in lowercase. I'm clutching my pearls.

  • Not a PHP programmer (unregistered)

    I am by far not fluent in PHP, but this line of code creates a variable amount of fields dynamically, which is kinda neat if there is such a requirement. The only WTF here is not writing the fields' HTML on the server side. Then again, that would probably look much uglier than this single line. I'd shrug it through in a code review and say meh... ¯_(ツ)_/¯

  • Robert Morson (google) in reply to Not a PHP programmer

    I'm not a PHP programmer either, but I know you could use a while loop to generate a variable amount of similar fields dynamically on the server side. It would be more maintainable, too, since the code for generating each one would be right there in the PHP, not hidden in some .js file. Also, the site would work (at least a little bit) in browsers that have javascript turned off, whereas this site probably just comes out blank with no explanation in that case.

  • (nodebb) in reply to Prime Mover

    Working in Fortran professionally. Out convention has the form "ABC_DoThisThing()", where ABC means that it is in "MODULE ModuleActiveBrineComponent". Industrial project, with earliest versions 20+ years old.

    Given all the WTFs of the language in itself I couldn't care less about capitalization of names, that the compiler ignores anyway.

  • dpm (unregistered) in reply to R3D3

    You disgust me with your longer-than-six-characters function names. Have you no concern for being FORTRAN-77 compatible???

  • (nodebb)

    Gah.

    This reminds me of a monstrosity i wrote some 15 years ago (Yes I'll confess, I did it):

    I wrote a perl CGI-file which outputted HTML code (pretty standard). This HTML included javascript. This javascript included using document.wirte to write HTML in a popup window created by window.open That HTML contained javascript to copy some user data from that popup window to the calling html and then close the window when it lost fucus

    So yes kind of an javascript+html inception thing. I distinctly remember i had to include 8 '' in order for the last one to survive in the inner javascript.

    I still get the shivers thinking about that one.

    The most amazing part was that it worked for 8+ years before we could finally take it out back and bury it 6 feet deep...

    Yours Yazeran

    Addendum 2020-10-01 09:19: Gah, the ting ate my backslash which was the one I had to use 8 of....

  • ooOOooGa (unregistered)

    PHP's array_map is a really cool way to obfuscate a foreach loop. I have never found any other purpose for its existence.

  • (nodebb)

    Capital HTML tags is the least of anyone's worries.

  • Shiwa (unregistered)

    They should migrate to node, so they could write JS to generate PHP to generate JS to generate HTML.

  • (nodebb) in reply to Shiwa

    Yo dawg

    More seriously, I could maybe see this approach being defensible if the page layout (and thus the implementation of CreateField) is expected to change around a lot, or if you're divvying up the work between a PHP person who doesn't know much CSS and a CSS person who doesn't know much PHP. But (1) there's no indication that either of those was the case here, and (2) there's probably still a better way to do it.

  • Sole Purpose Of Visit (unregistered) in reply to emurphy

    Um, templates?

    The things seem to have gone out of style these days, but my first instinct when interfacing between any language at all and the DOM is, why not use a flexible tool that is designed to do this?

    Haven't gone near Web design in ten years, so I'm talking through my trumper as usual.

  • Edd (unregistered)

    Generate a universe for each element and have the inhabitants figure out where to put the element

  • Robin (unregistered)

    This is all too typical of the rubbish that PHP seems to generate. Now I know full well that none of the idiocies in this code are due specifically to PHP, and that some developers are well capable of similar rubbish in any server side language (as we see on this site on a daily basis). But nonetheless, atrocities like this seem to occur disproportionately with PHP. (Look at the code for more or less any Wordpress plugin, for example. ) I have my own firmly-held belief as to why that is, but had better not say it for fear of starting a flame war...

  • DotToy (unregistered) in reply to Robin

    I did PHP professionally for years, and here's my take on it: while PHP is a fully capable language that can be used to make well formed code, it's also very easy to learn on your own which almost always leads to bad habits and horrible practices. That ease of learning makes it accessible, while also causing a lot of code smell in the process.

  • (nodebb) in reply to DotToy

    PHP is a fully capable language that can be used to make well formed code

    I've got bad news for you; every language, except those specifically created as jokes (Google esoteric programming language some day), meets this criteria. It's pointless to even say it.

    These are the types of things that a good programming language has:

    1. On those days where you didn't get enough coffee, you get a clear error message soon after you make the inevitable mistake.
    2. Allows you to express your intent concisely and accurately.
    3. When a mistake gets into production, the tools exist to identify the bug quickly.
    4. Rich ecosystem of high quality libraries that meet your needs.
    5. Large and helpful community.

    Note: I realize that only #1 and #2 are actually attributable to the language itself. But a good language with no support should not be used in for-profit enterprises.

    Any time you have to scrape the bottom of the barrel and list the virtues of a language as:

    1. Can write any program
    2. Allows you to catch errors
    3. Supports comments

    ... you are talking about a language that has no virtues.

  • J. (unregistered)

    The nice thing is there might even be an XSS vulnerability in there, you just need to get </script> into $value or whatever and can then open a new script tag with access to the full glory of javascript (as long as it is not broken by json_encode, but fuckjs would meet that requirement). So if the data is not static / can be controlled by the user (and they obviously have no CSP) this code got even worse.

  • NoLand (unregistered)

    For 1998 it isn't that bad – mind the upper-case script tag (but it's missing the language attribute)! Backend guy doesn't mind JS, as quite common at the time. Even $sep makes sense: Netscape Navigator 3.0 had a bug, where it would generate any inline-objects (images, etc) twice, when the content was generated by document.write() with adjacent white-space inside a td element. So $sep adds some context sensitive fix for this: if inside normal text, prefix it by a blank, if inside a td, make sure it's an empty string. (Otherwise, if this is some more recent code: does Stackoverflow serve answers from the 1990s?) ;-)

  • 516052 (unregistered)

    What's wrong with uppercase HTML? I'd rather have that than lowercase as it is by far more visually distinctive and thus human readable as it draws your eyes to the tags and away from the content. Something that is valuble when you are editing the files by hand as was done back in the 90's.

    Kids these days are just spoiled if you ask me with your editors and frameworks and CSS. Back in my days we used tables and if you were reall fancy frames. And we did all our HTML editing in a text editor.

  • (nodebb) in reply to 516052

    Yeah, and you walked forty miles uphill in the snow both ways, right?

  • 516052 (unregistered) in reply to Steve_The_Cynic

    Say what you want, but I kid you not when I started working with the web I did in fact only have notepad, raw HTML and tables for formatting. CSS was just coming in and wasn't properly supported by half the browsers. Javascript was... flaky and everyone was griping about why nobody but IE-whatever from windows 98 was supporting ActiveX.

    The frameworks you see today are literally from another planet by comparason. And I can't help but feel that in going over to them, in particular in having people start with them as opposed to raw HTML we have lost something in the translation.

  • (nodebb) in reply to 516052

    Windows 98 was IE4, which could at least do HTTP 1.0. Windows 95 OSR2 had IE3, which only knew HTTP 0.9. When I put it in a VM in 2000 or 2001, I couldn't download a more recent version because Microsoft's own site refused to answer it.

    But you're right - something has been lost, roughly the same something that was lost in non-Web development in the transition to progressively higher-level languages.

  • David Mårtensson (unregistered) in reply to Not a PHP programmer

    I agree this example is a bad code.

    That said there are cases where sending data in JS instead of html fields is a good thing.

    But, you would not send document.write commands ;) but rather a json and then a script that uses dom methods to generate fields.

    This can be viable if you know you are going to create massive amounts of fields, like multiple thousands, since parsing the HTML is slower than parsing Json.

    And generating the fields programmatically means the page can load much faster.

  • Jens Svensson (unregistered)

    The problem with PHP isnt that monkeys can code in it, it is that many do......

    What is it with PHP that makes people write so much shit, you can write shit in all languages but it is so much more frequent in PHP.

    Nice to remember why I stopped working in PHP.

  • van Dartel (unregistered)

    Essence: PHP (the server) is responsible for determining that some field is needed. It then passes on the specification of that field to the client. JavaScript (the client) is responsible to present that field in whatever way it fancies (as long as that implementation adheres to the specification).

    Great! The server need only be concerned that e.g. it needs an input for X in the range 0..10, and the client need only be concerned that such a specification can (e.g.) be implemented as <label>Enter X: <input type="range" min="0" max="10"></label>.

    At the coding level it's a bit messy though (global window variables, $sep has a cosmetic purpose at best, implode+array_map+json_encode is a syntactic bridge that could have been encapsulated, usage of uppercase tags lags (X)HTML evolution, the alleged usage of "document.write" and a script per field).

  • 516052 (unregistered) in reply to David Mårtensson

    If you work hard enough you can find good reasons to do just about anything including placing your soft bits into a running woodchipper. Don't mean it's not a mostly bad idea most of the time. :P

  • (nodebb) in reply to Not a PHP programmer

    I have no idea how you ended up in a position to be reviewing code? But it's people like you who let the NSA sabotage the OpenSSL Project, no where did I leave my tinfoil hat.

  • (nodebb) in reply to 516052

    I kinda agree with you, I'd like it if tags were by convention capitalized, but they're not. So I'd prefer a standard convention than a mixture of both. These days if you're not one of these "kids" using any number of free editors (but ironically enough, somehow even VI was dethroned by VS Code) that give you appropriate syntax highlighting and built-in linting plugins. It's really time to spend some time sharpening your saw, as it makes life a LOT easier.

  • (nodebb)

    And here I was thinking that the WTF was to JSON encode each element separately and then imploding them together instead of just JSON encoding the whole thing in one go, something like this:

    echo $sep . "<SCRIPT>CreateField(" . substr(json_encode($argv), 1, -1) . ");</SCRIPT>\n";

    Or if you're feeling really lazy, then this:

    echo $sep . "<SCRIPT>CreateField(..." . json_encode($argv) . ");</SCRIPT>\n";
  • I'm not a robot (unregistered) in reply to caffiend
    I'd like it if tags were by convention capitalized, but they're not
    alert(document.documentElement.tagName) begs to differ (in an HTML document at least).
  • Some Ed (unregistered)

    I don't know about other people, but most of the pages I've seen with a lot of javascript code seem to at some point or another do this sort of crap: generate code that could have and should have been generated server-side. I've seen some stuff that will generate that HTML code by making additional server-side calls that could've been simple includes, and others that would actually pass the JSON to generate the HTML back to server side for the actual expansion (I guess someone thought Javascript might want some help parsing JSON for some reason. That's one of those Object Notations, isn't it? Whose object notation is it again?)

    To be clear, all the bits I'm complaining about are instances where all of the data the JavaScript code is using to generate the page are in the web page generated for the user. It's not pulled from some other JavaScript library, it's not read from the user or from their data files or anything. I'm not at this point in time objecting to the use of JavaScript to do stuff on the client that could only be done there. Just stuff that the server could've generated as HTML, but didn't. It just feels like the main purpose of doing things in this backwards way is to force people to run active scripting enabled browsers.

    Well, maybe that and also generate more web page hits, simulating higher traffic volumes on the server artificially.

Leave a comment on “Imploded Code”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article