Change:
Your code should use `typeof` in two `console.log()` statements to check the type of the variables. ```js <del> assert(code.match(/console.log(typeof[( ].*)?)/g).length == 2); </del> <ins> assert(code.match(/console.logs*(typeof[( ].*)?)/g).length == 2); </ins> ``` Your code should use `typeof` to check the type of the variable `seven`.

Discussion:
The test regexes don't allow for spaces before the parentheses, which is unnecessarily strict. Same as:
What do you mean by "unnecessarily strict"?
Compare the two code examples — only one passes, while both should. The interpreters don't care about spacing, so neither should these exercises. You can look at how was handled if you want to give it a go.
I'm not wild about relaxing the tests to support irregular/unusual formatting. It's uncommon to stick spaces between the function/method nane and the ()s for the argument list in JS.
People do it, otherwise we wouldn't be careful about it in most tests. I guess my student keeps doing it because it's the norm in natural languages. FCC doesn't teach or enforce style and I'm sure you know code formatting is a major source of bikeshedding anyway. Silly details like this shouldn't get in the way of learning.
If you call a method with a space between the name and parentheses then that method would not work. Why promote bad syntax when learning?
Some people do it but it is really uncommon. Making the code readable to other people is part of getting hired. This just isn't a thing that you see in production code. JS has a bunch of these little things that are technically possible but never used. There is a huge difference between bikeshedding on indentation or semicolons and going out of our way to support baffling, non-standard syntax that nobody uses in professional code. We're made notes about this sort of thing in the past so learners don't get in the habit of writing technically correct but bizzaro code: And all of our examples of using functions follow the basic convention in JS of not jamming extra spaces in there, from the beginning: I don't see why we'd be obligated to support every single non-standard thing that a learner can imagine.
I see here that we seem to be moving towards intentionally supporting users writing confusing syntax. In light of this, we should remove the note here I personally think this is the wrong call, but we should be consistent.
That's demonstrably false. Well, we've already been doing this spacing leniency for ages, so it's not like I'm proposing some novelty. Or anything absurd (your strawman of "every single non-standard thing").

I count uses in between 400-500 of our test asserts, so they're pretty much everywhere. If we wanted to enforce style, we would have tests for that, not letting unrelated tests fail and be opaque at it. It just breaks the learning flow, so I can completely understand why we do it as we do. Forceful automatic code reformatting would also be silly.
We have 400-500 asserts designed to allow spacing inbetween the function name and ()s? Odd.
The spacing leniency is not limited to that one case, of course ...
I agree with but the people who type should get more descriptive fallback error instead because in console it logs and , when the code above is used. maybe changing this to
i think we should run that wrong syntax but at the same time give warning about the syntax begin wrong and also the correct syntax.
Neither syntax is incorrect, one is just less common. There is already wide support for being lax in tests like these. Most recently the discussion was in the previously linked , where the core team weighed in as well. So the main thing that should be done in this bug is just to fix the tests. Other bugs should have their own issues.