• (nodebb)

    When the only tool you have is a hammer ... everything gets damaged.

  • (nodebb)

    Slightly disappointed. When I saw this

    When this person started, the team had some regular jobs which ran in the mornings.

    I was expecting that at some time shortly after this person started, the team no longer had any regular jobs that ran in the mornings.

  • (nodebb)

    Or the way that, after our main while loop, which we'll come back to, we compare boolean variables against boolean literals.

    And that he does not do it consistently!

  • (nodebb)

    I waited 3 minutes to post this

  • (nodebb) in reply to ESkIiHccraVBD

    Y'all are gonna hate me, but I always test boolean variables as "if (okay)" and "if (okay == false)". Sometimes the exclamation point is hard to see, but at least I'm consistent.

  • Acronym (unregistered) in reply to dpm

    I'll do one better. In TS I convert to boolean by using Boolean(test) not !!test. For the same reason, the double exclamation marks is hard to see and may be confused with a single excalamation mark

  • (nodebb) in reply to Acronym

    Have you considered a career as a lawyer instead?

  • (nodebb) in reply to dpm

    In Python, the exclamation mark is a not and hard_to_see != False

  • A Human (unregistered) in reply to dpm

    I am going to hate you, because it can be written clearer as if okay and if !okay.

  • (nodebb)

    My first thought looking at this code was that given there are three boolean variables, and different logic to run based on different combinations of values, it may improve readability in this case to say "if (bool1 = true and bool2 = true and bool3 = false) {} else if (bool1 = false and bool2 = true and bool3 = true). {}..." etc. That way you can see at a glance which specific combination is being treated by each block of code. But then I saw the "if not hub_1_ready and not hub_2_ready and job_ran_later == False:" and can only shake my head and walk away.

  • (nodebb) in reply to A Human

    I am going to hate you, because it can be written clearer as if okay and if !okay.

    Not in every programming language.

  • A Human (unregistered) in reply to Dragnslcr

    Well no.

    But neither can if (okay), if (okay == false),if not okay,if [ $okay -ne 0 ],if okay == False, orif (okay === true)`. In fact, I don't think there's anything that would work in every programming language.

  • notreg_253 (unregistered) in reply to ESkIiHccraVBD

    In Python you can use not as well as !.

  • aMinuteTree (unregistered) in reply to Acronym

    The only sane reason to prefer double negation over a cast/explicit coversion is using a lame language where the latter does not exist. A cast is the semantically correct choice, you want to convert a non-boolean into a boolean, you don't want to take a negation of a negation (which should logically be the original, relying on such an operation to do anything at all is a hack)

  • (nodebb) in reply to A Human

    Then why would you hate someone for writing if (okay) when if okay isn't valid syntax for the language?

  • 516052 (unregistered) in reply to aMinuteTree

    Unless of course you overload the ! operator to do something other than just negating. As in, have a custom class that uses the ! operator to "logically" negate a number of the fields by flipping their internal value to settings opposite of what the setting was. And no, we are NOT just talking about boolean values. We are talking about complex custom object types, well structs since this was old C++, changing their internal state. And yes, the code is naturally not available.

    How did I come up with this? I didn't. As to where I found it you don't want to know.

  • (nodebb)

    Operator overloading is one of those ideas that sounds great in theory, but really, really invites danger in practice. If there was a way for the language and compiler to enforce "similar" semantics on overloaded operators as they naturally have, that set of guardrails would prevent the worst abuses. Such as enforcing no side effects. For operators that are typically commutative, e.g. + enforcing commutivity on the overload, etc.

    The real value of SomeMethod( Argument1, Argument2) over Argument1 (some common math symbol goes here) Argument2 is the former invites you to wonder how SomeMethod really works on these argument types, while (some common math symbol goes here) strongly invites you to assume a standard implementation of the math idea you've known since school.

  • (nodebb) in reply to WTFGuy

    Operator overloading is one of those ideas that sounds great in theory, but really, really invites danger in practice.

    the C preprocessor. Really powerful and a lot of fun to write code with, but absolute hell to maintain.

  • (nodebb) in reply to WTFGuy

    Such as enforcing no side effects.

    The "++" operator would like a word with you.

Leave a comment on “Three Minutes”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article