Why Do Results Vary Based on Curly Brace Placement

Why do results vary based on curly brace placement?

That's one of the pitfalls of JavaScript: automatic semicolon insertion. Lines that do not end with a semicolon, but could be the end of a statement, are automatically terminated, so your first example looks effectively like this:

function test()
{
return; // <- notice the inserted semicolon
{
javascript: "fantastic"
};
}

See also Douglas Crockford's JS style guide, which mentions semicolon insertion.

In your second example you return an object (built by the curly braces) with the property javascript and its value of "fantastic", effectively the same as this:

function test() {
var myObject = new Object();
myObject.javascript = "fantastic";
return myObject;
}

Do C# results vary based on curly brace placement?

No, they don't.

In JavaScript, you can write code without ending your lines of code with a semicolon, and JavaScript will automatically fill in the missing semicolons when it interprets your code. That's what this answer to the question you linked is essentially stating. That is to say: the brace placement isn't the real issue in JS; it's the ability to write code with/without semicolons and have JS automatically fill these in for you. The brace placement issue is more of a side effect of this functionality.

In C#, a "line" doesn't end until the semicolon is reached (even if that "line" spans multiple physical lines), and writing code without semicolons isn't something that is automagically taken care of for you by the compiler; it will simply fail to compile. The brace placement in C# therefore is unimportant.

Javascript Object - Why does it behave like that + Braces around object name

Its because with curly braces it becomes create a destructuring. Otherwise in order to access the object values you need to call object associated with that property.

    let  {name, age } = {name: "Faraji", age: 23};
console.log(name, age);

Why does the position of braces in JavaScript matter?

Because of automatic semicolon insertion. The first code is the same as

function func1() {
return;
{
foo: 'bar'
}
}

If you wonder why this code doesn't produce a syntax error, foo: is a label.

Regarding

Is it a language feature or a bug?

It's a feature. But a very dangerous one. The best way to keep it being a feature for you is to stick to consistent formatting style (I'd suggest to use the Google style guide until you're experienced enough to make your own).

When mutating a module object, why are curly brace imports not changed?

This is related to When the variables/constants are created.

Import is "executed" before you mutate your object and the constant foo, is then created before you mutate React.foo.

const obj = {a: 1, b: 2};
const a = obj.a; // import
obj.a = 42; // your mock injection

console.log(a); // it will keep returning 1

The way this is handled, is that when a (foo or useContext in your example) is created, it points to the position of memory hold by obj.a, which contains a 1 in the moment of creation. Then obj.a points to a new position of memory where a 42 is stored, but obj.a and a are independent one to another.

In your case my recommendation is to use a Dependency Injection solution.

Either App receive a parameter for which dependency it needs, and then you mock it in the test. <App foo={myFooMock} /> or another usual solution is to sent a context, and have a context creator for Tests with mocks and a context creator for production app.

const myMockedContext = {foo: 'foo', useContext: jest.fn()};
const { getByText } = render(<App context={myMockedContext} />);

Normally you would want to have as much of your real code in your test as possible, all your business logic so that your test fail as soon as there are changes in interfaces or error in type returns or any other unexpected behaviour among your different areas of code.

But this is an ongoing discussion between Mockist and Classists in the TDD community.

HTH

Arrow function runs perfect without curly braces. Added curly braces{ return } and it breaks

You're falling victim to a "trap" in the semicolon insertion rules. After a return, a semicolon is assumed if an expression doesn't start on the same line.

If you change your function as follows, it should work:

function displayMatches () {
const matchArray = findMatches(this.value, cities)
console.log(matchArray)
const html = matchArray.map(place => {
return `<li>
<span class="name">${place.city}, ${place.state}</span>
<span class="population">${place.population}</span>
</li>`
}).join('')
suggestion.innerHTML = html

}

JavaScript formatting: must braces be on the same line as the if/function/etc keyword?

Yes, it matters in certain corner cases.

And the problem isn't with "browsers incorrectly interpreting it". The dodgy behaviour is correct according to the ECMAScript specifications. A JavaScript implementation that didn't exhibit this behaviour would not be spec-compliant.

An example. This function is broken:

function returnAnObject {
return
{
foo: 'test'
};
}

It's supposed to return an object, but actually returns nothing. JavaScript interprets it like so:

function returnAnObject {
return;
{
foo: 'test'
};
}


Related Topics



Leave a reply



Submit