This week in: Code from the Wild


What do we want!?!

Animation! :fist:

Where do we get it from!?!

The animation property…

Of what!?!

The… animation…


You never know… it could use WAAPI.

const animation = () => Element.animate(getAnimation(animation.animation), getAnimation(animation.timing))

1 Like

This one is an oldie but goldie (and I believe I may have posted it before somewhere else on kirupa), but one of my favorites and it fits the topic:

// Add one to the iterator

Seems intuitive enough to me. :joy:



I wrote some code like this recently (which I’ve stripped of its actual functionality):

func f<TType>(_ p: [TType: Float]) {
    if type(of: TType.self) == UType.Type.self) {
        // ...

Definitely felt like I could have found a better way, but I unexpectedly found myself wanting to reduce code duplication when the previously nongeneric function needed to work on a new enumeration type (in the dictionary).

1 Like

(Some names have been changed to protect the innocent.)

This is some test code using an assertion library called Chai. The test this code ran in passed, but it shouldn’t have. And while the assertion looks ok, since many of the assertions in chai work this way…

// good

…the original actually has a fatal flaw: throw needs to be called as a method. What the code should look like is:

// correct
expect(() => instance.method('bad-input')).to.throw();

In this format, it will now fail when instance.method() fails to throw an expected error. When throw isn’t called as a method, the assertion doesn’t know to try to run the expect value as a function and check for errors. That then allows for non-throwing, but should be throwing, methods to incorrectly pass the test.

This issue was picked up in a code review, so we were able to fix things up before bad code got submitted to mainline, but it can be easy for things like this to slip through. Stay vigilant!


You should switch to Wallaby JS mate… :smile:

1 Like