• Biri (unregistered)

    Oh this is beautiful... there is beauty in madness, right?

  • Second (unregistered)

    var self = document.querySelectorAll("frist")

  • I am a robot (unregistered)

    at least its indented

  • David Hemming (google)

    This is one of those rare occasions where it would be better if it weren't indented.

  • Daniel (unregistered)

    Meh. Looking at the variable names, this is clearly minified JavaScript that went through the browser's built-in formatter. Nothing particularly egregious...

  • (nodebb) in reply to Daniel

    Nothing particularly egregious? You're kidding, right? You could stuff the data into an associative array at half the character count and (assuming a bad optimizer) twice the performance. You could keep the data separately and call back to get it. You could derive it from the <options> to a <select>. I know there are worse ways to write this code, but is there a worse one that's plausible?

  • Quite (unregistered)

    Ba!

  • Jamtex (unregistered)

    Someone got paid by the line.

  • MiserableOldGit (unregistered) in reply to TwelveBaud

    I can't see performance being an issue with a weedy little thing like that, and I'm not utterly convinced you'll get something better with an array versus having it fully unrolled. Mind you if the coder (or auto code generator, which I suspect it could be) was going to do that with it, it really should have gone with a switch statement!

  • dpm (unregistered)

    TRWTF is that there is no default value being returned.

  • Sam (unregistered)

    See, this is exactly how you make secure, maintainable and reliable software. Fire the programmer and use an auto code generator. Software for things like car engines, airplanes, spacecraft are written this way.

    You make a model and a spec that's high level, often GUI, and that is written in engineering terms. Then you test the heck out of the model, say simulating sensor failures and running real-world data through it. Now you have a very reliable model, how do you translate it to executable code on the device without errors? Use a completely automated process.

    The resulting code may look awful, but you never deal with it at that level, and in fact, the generated code may be faster. Even if it isn't, just throw a faster processor at it.

    It's just like saying that compiler generated machine code is ugly and potentially inefficient compared to hand generated assembly.

  • questing (unregistered) in reply to dpm

    Hmm, is that not the final } else { return "" }

  • Zenith (unregistered)

    It's like they've never heard of a case/switch statement. I work with code like this except instead of nested if/else it's stacked ifs. Performance dies a death of a thousand cuts.

  • Daniel (unregistered) in reply to TwelveBaud

    There are better ways to write it, for sure, but again, this is not particularly egregious.

    “Assuming a bad optimizer”? Chained if statements over integers are trivial for today’s JS runtimes. The compiled output would be the same as a switch statement, and they would inline it if this function got called enough. But this point is moot anyway, because there are no realistic situations where this would ever be a performance problem, so even talking about “twice the performance” is absolutely needless premature optimization.

  • (nodebb)

    Performance of nested/stacked if's vs. an array vs. a table may have been an issue with Firefox 3.0. I suggest you upgrade to something more modern.

  • (nodebb)

    function a6(ba) { return (function (chosen) { return typeof chosen === 'function' ? chosen() : chosen; })(([ function () {return ad.find("#wireless-channel-auto").text();}, "1 - 2.412 GHz", "2 - 2.417 GHz", // ... ])[parseInt(ba)]); }

    Fixed the indentations, but made it weird...

    Just like my relationships.

  • Zenith (unregistered)

    What part of "death of a thousand cuts" did you miss? This could be happening all over a 60K-line script. At some point, the developer has to do some thinking, because renting more processor/storage/bandwidth and/or lurching your entire stack through an update treadmill isn't acceptable.

  • Gummy Gus (unregistered)

    Apparently the coder did not twig to the realization that the channels are 50KHz apart. Knowing that the function becomes: return ba + " - " + ba * 0.05 + 2.415 + "GHz"

  • jmm (unregistered)

    This code was generated by a tool.

  • Chakat Firepaw (unregistered) in reply to jmm

    That's true of most of the code featured on this site.

  • prexit (unregistered) in reply to jmm

    Lets not resort to name-calling

  • Brian Boorman (google) in reply to Gummy Gus
    that the channels are 50KHz apart
    You mean except when you jump from S-Band up to C-Band frequencies? Bad code style is one thing. Code that is functionally wrong is another altogether.
  • John A (unregistered) in reply to jmm

    I agree. Most tools transform switch statements into nested ifs. So the only decision here was to populate the UI using hard coded values, or look-up from a file/db. I think for something lightweight and immutable the best course of action is switch statement. Granted if there is a formula (like 50kHz steps) that would make more sense to use, but in this case "good enough = product shipped".

  • foxyshadis (unregistered) in reply to Daniel

    "Chained if statements over integers"

    I guess you didn't notice the quotes around the tested numbers....

  • Sam (unregistered) in reply to Gummy Gus

    Isn't that more of a performance WTF, cause now the JS engine has to deal with a float? Watch some crappy platform populate the list with "1 - 2.4119999999999999999999999 GHz"

  • bobcat (unregistered) in reply to Brian Boorman

    Eh, that's just an if statement, easy peasy. They probably didn't read out the whole list to see there was a jump.

    ... Huh. Two jumps.

    Okay, I think TRWTF if happening off-screen, as there is a cluster of values on the end that belong in the middle. I mean, it doesn't need to be in ascending numerical order the way they have it, but it just seems very odd. My money is on 'oops, we forgot those and now we can't adjust accordingly, we'll tack it on the end of the list and hope nobody notices'.

  • jan stroopwafel (unregistered)

    <select><option>hoi</option></select>

    why would you want to end <select> tags when they don't do anything?

  • Daniel (unregistered) in reply to foxyshadis

    Indeed! My bad.

  • nasch (unregistered) in reply to Sam

    How do you know the code generator is better than a human? After all, it was written by a human.

  • Sam (unregistered) in reply to nasch

    Two reasons: first is the code generator can be split up into much smaller blocks that can be individually validated. This is like a compiler. You implement and test arithmetic functions independently, then you can put them together to form arbitrary equations at a high level of certainty.

    Second is a cost issue. The code generator and libraries can be reused over multiple projects, platforms and companies, thus the cost of validation is amortized. The overall validation can be more comprehensive and cross-domain (aerospace, automotive, medical, industrial) compared to starting from scratch every single project. This is important due to the fact that many of these systems run on bare metal: no operating system.

  • TheCPUWizard (unregistered)

    If people keep writing code like this, there will soon be a worldwide shortage of curly braces [it was the shortage of parenthesis a few years ago that killed Lisp -Right?]

  • Batou (unregistered)

    I'd say this kind of code would work better as a switch, but since this is for a router...

  • Ray (unregistered)

    This isn't even the worst I have seen when it comes to a routers web-config sourcecode.

    A lot of el-cheapo modern routers still do the stupid thing (I was kinda hoping it had of died off years ago) where they store the default login details in the sourcecode, a simple 'view source' shows that the JS does validation to make sure what you entered and what it is expecting are the same.

  • Anonymous (unregistered)

    This is why I use OpenWRT.

    There are two things that I'm sick of in consumer routers: arbitrarily limiting the capabilities of the device when the hardware is capable of more just to make people pay for a more expensive model with extra features (e.g. firewall, VPN, extra WLANs, etc.) and devices that don't actually do half of the advertised features properly in the first place (or feature slow/bloated/badly-written code that makes them difficult to configure or use).

  • NotARobot (unregistered)

    Anyone care to elaborate which router this is?

  • doubting_poster (unregistered) in reply to NotARobot

    all of them.

  • NotARobot (unregistered)

    WTF? Spambots at TDWTF? Oh my. Seems like that CAPTCHA of yours has been beaten.

  • fragile (unregistered) in reply to Sam

    Problems with your approach:

    • Smarter people with a lot more resources have tried this. The best they came up with is HTML/CSS and JS. If there's an easier way, they either came up with it in a preprocessor for a specific application, or it doesn't exist for some reason
    • With something like labview, you have total control of the enviroment. If a sensor operates out of bounds, you're not liable. If your website leaks customer information, you're liable no matter what happened.
    • Inner platform effect, you'll spend more time updating your visual builder than the actual product, or build a visual builder for a visual builder
    • Things change fast on the web, and it's hard to keep up. A lot of Visual Builders promise RWD, but I haven't found a good one.
    • Projects are very specific. You'll have a visual builder for every site
    • There's momentum against reinventing the wheel. DDWRT already exists. Just drop that in, and code that how you want it. Teams who are good at something already know wordpress. Why risk loss for something untested?
    • Odds are a competitor will come along with a better interface or design element that beats you because you're limited by the platform. The longer you do it, the higher the odds stack against you
    • Bigger talent pool with the underlying code to build your team. Far fewer people with your specific visual builder.
  • Axel (unregistered) in reply to TheCPUWizard

    I had to stop using MS Paint because my monitor was running out of red pixels.

Leave a comment on “A Bad Route”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article