• Michael R (unregistered)

    -Frist

  • (nodebb)

    I'm glad that when I work with hardware like that, I can use Python and libraries that handle this stuff for me.

  • (nodebb)

    And of course UInt16, no matter how you capitalise it, is the wrong internal data type for five-digit numbers anyway.

  • Greg (unregistered)

    W.r.t. rounding errors, they would probably have been better off inserting a decimal point/adding trailing zeroes in the value string before parsing as a double.

  • (nodebb)

    I also like the function name vs signature: public double ConvertIntToDecimal(...

    Given that the language has numeric types called both double and decimal how about the name it
    public double ConvertIntToDouble(... Or better yet
    public double ConvertIntWithFractionToDouble(...

    Or even better, create an object /struct that captures the two string values and exposes the value as a double (and/or a true decimal)

  • (author)

    " they're mistake is an easy mistake to make " I was so sure this was a clue.

  • (nodebb)

    Isn't a big chunk of the WTF here is on Janet's company? How did they pay the contractors and release them from the contract before actually checking if what they wrote worked at all? I admit I haven't worked myself with the kind of HPCs that do one project and skitter off, but that seems really financially irresponsible.

  • (nodebb)

    Fixed point arithmetics, pretty common in the embedded world.

  • Richard Brantley (unregistered) in reply to dorner

    Poor management lets a lot of consultants off the hook. I've been at companies that used to just throw work over the wall at them and take back whatever they produced with no review and no testing, mostly because the work was handled by non-technical managers who didn't understand and didn't care.

  • PedanticRobot (unregistered)

    Nothing sets my teeth chattering quicker than inconsistent casing. Especially in C# where the casing conventions are relatively simple, if you can't handle or can't be bother to follow those few rules, then there's no reason to think the rest of your code is written with any more care.

  • Nope (unregistered)

    They're mistake? Seriously?

  • Argle (unregistered)

    Ask programmers to test? scoff

    Seriously, testing isn't a lost art. Sometimes it's not even a found one. In a number of my classes (usually about 2/3 professional programmers) I describe a hypothetical program that reads in a line of user input with 3 comma separated lengths of a triangle's sides. The program determines if it's a valid equilateral, isoscoles, or scalene triangle. I ask them to come up with as many ways to test this as possible. After getting no more than 5 or 6 lines of test cases from any of them, I proceed to floor them with (and this is just partial and only the first 3 should succeed):

    1,1,1 1,2,2 1,2,3 -1,-1,-1 l,1,1 1,1 1 2,2,80 one, two,three 4,4,4,4 equilateral ,, , ,,, Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean mauris ipsum, lacinia sit amet augue vitae, porta accumsan mi. Sed ante urna, tristique vel pulvinar tincidunt, lacinia ut turpis. Suspendisse ante risus, venenatis sed ullamcorper vehicula, tempus ac justo. Nulla id vulputate ligula. Vivamus tincidunt libero lorem, eu tristique ante volutpat id. Cras id erat luctus, pharetra lectus sed, aliquam lacus. Sed at ultrices odio, sed posuere justo. Nunc fringilla tellus vitae libero rhoncus facilisis. Nulla placerat egestas varius.

  • John (unregistered)

    Why not convert to double before doing the division and skip the integers alltogether.

  • Officer Johnny Holzkopf (unregistered) in reply to WTFGuy

    Not only does the method name mislead about the method's purpose, the comment header isn't helpful either. Maybe there is a policy to blindly follow: "Always use the Java automatic documentation features, so the documentation will write itself!" This has been done, obviously without using any brains, even though the summary is wrong, as it doesn't set the "single parameter" value, nor does it set the single parameter called "value", also the parameter "Value" does not contain the name of the parameter as suggested, and "decimals" is completely ignored. Finally, nothing is said about what the method returns. Is stuff like this one of the very typical things you are supposed to find in HPC "work" results? And people PAY for that?! Strange world...

  • xtal256 (unregistered)

    "It seems likely, at this juncture, that the HPC simply never actually tested the code."

    Oh, I'm sure they tested it. Their test data: 12345 2 11111 3

  • Anonymous (unregistered) in reply to Argle

    QA Engineer walks into a bar and orders a beer. Orders 0 beers. Orders 99999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd.

  • (nodebb)

    What I like most about this is that the code in the then-branch should work perfectly fine for zero and negative decimals. The dev introduced a special case that isn't actually a special case, just to handle it wrongly.

  • (nodebb)

    The hardware in question was a scientific which communicated over a serial line.

    There's a missing in this sentence.

  • Domin Abbus (unregistered)

    This one hit a bit too close for comfort. In my (inherited) system, and integer is assumed to be "floating point" with one decimal. Usually. If you expect the number to be larger than 3000, then it is no decimals. (only "documented" in the source code.) The airflow sensor (up to 200000 m³/h) you add an extra zero. Obviously. Also not documented. I'm still spending time rewriting / refactoring the code to use floating point. (and yes, a lot of division and multiplication factors cancel out. It turns out that, for units of measurement at least, the code becomes somewhat more readable.)

Leave a comment on “Consultant Conversions”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article