• (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.

Leave a comment on “A Percise Parser”

Log In or post as a guest

Replying to comment #690878:

Log Out

« Return to Article