• (nodebb)

    It was much more effort to understand how this code happened in the first place.

    The same way it happens anywhere: one misstep at a time.

  • Rob (unregistered)

    Performance is obviously not a thing, because they're calling value_.split( ',' ) three times, and using value_.split( ',' )[1] twice. They're also potentially callingparseInt( value_.split( ',' )[ 1 ], 10 )twice. (They also could have used the result ofvalue_.indexOf( ',' )` instead of splitting...)

    And parsedCommaValue is a number if it's < 9, otherwise it's a string.

  • 516052 (unregistered)

    Performance is obviously not a thing given that they are using javascript.

  • kythyria (unregistered) in reply to 516052

    There's the language being slow, and then there's writing a slow algorithm in that language. This is the latter, it would be slow in any language, if you could write it at all without triggering a type error. That "string or int" thing can't be helping performance either, subsequent code cannot use fast paths that rely on knowing the real type.

  • (nodebb)

    Sorry, that was as far as I got before I bailed.

    Addendum 2026-02-03 09:07:

    let value_ = value;

  • (nodebb)

    In addition to all the other sins, handleInput is a really vague name for a number-parsing function.

  • who wants to know that? (unregistered)

    My favourite part is the parseInt on the decimal part getting rid of leading zeroes, so e.g. '2,04' turns into 2.4.

  • (nodebb) in reply to 516052

    Performance is not an issue because they're dealing with user input, typed one character at a time, into a textbox with no more than, say, 20 characters. N is so small that they could have an 2^n algorithm and almost be fast enough to not be noticed by the user.

  • NoLand (unregistered) in reply to who wants to know that?

    My favourite part is the parseInt on the decimal part getting rid of leading zeroes, so e.g. '2,04' turns into 2.4.

    Actually, if there is more than a single fractional digit, the fractional part will be still a string, limited to two characters. So it's 2 + "04" (number + string), resulting in the string "204", which will then be processed by parseInt(…, 10) / 100 into the real value 2.04. So this actually works.

  • (nodebb) in reply to Rob

    Agree w @PotatoEngineer & @516052.

    As long as the code you are writing runs on their client, you do NOT care how performant it is or isn't. Any brain bytes spent on performance there are 100% wasted. Total opposite for code that runs on your server; performance back here is almost always a strong consideration.

    But the performance we all should be caring about is the gain that comes from using an adequate language and adequate libraries by devs of adequate knowledge so this kind of trash code never has to be written, debugged, or maintained.

  • Darren (unregistered) in reply to WTFGuy

    I hope this comment - "As long as the code you are writing runs on their client, you do NOT care how performant it is or isn't. Any brain bytes spent on performance there are 100% wasted." - is you being sarcastic.

    Otherwise, you've just absolutely demonstrated what's wrong with modern (last 30 years) development. This attitude of 'I can write crap code, it doesn't matter, we'll just tell the customer to get more RAM / CPU / storage' is a cancer on the industry.

  • (nodebb) in reply to Darren

    Agreed. We don't have control over the user's device, so Postel's Law (https://lawsofux.com/postels-law/) is very apt. There are a lot of folks out there who for various reasons don't have the option of simply upgrading to the latest and greatest software, hardware, and network connectivity.

  • who wants to know that? (unregistered) in reply to NoLand

    Actually, if there is more than a single fractional digit, the fractional part will be still a string, limited to two characters.

    No, you read the code wrong. The check isn't if the fractional part is more than a single digit, the check is if the fractional part, parsed as int, is less than 10 or not. parseInt( '2,04'.split( ',' )[ 1 ], 10 ) < 10 returns true.

    Try it if you don't believe me.

  • NoLand (unregistered) in reply to who wants to know that?

    You're right!

    (All those value_.split( ',' )[ 1 ], 10 ) must have confused me. No sense in spli()-ting hairs on that…)

  • Officer Johnny Holzkopf (unregistered) in reply to Maia-Everett

    Things like handInput() fit nicely into a world where things like doTheThing(), doOtherThing(), performOperation(), calculeResult() or decideAboutOption() already might exist.

  • Roman Seidelsohn (unregistered)

    Oh, now I get it. I'm sorry for my "wise" comment recently. I guess when a function is calculating percision, one should not expect precision exactly.

Leave a comment on “A Percise Parser”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article