Error in a problem set that should be clarified for future users

[triangle4studios]

Some how this is correct:

function checkScope() 
{
  "use strict";
  let i = "function scope";
  if (true) 
{
    let i = "block scope";
    console.log("Block scope i is: ", i);
  }
  console.log("Function scope i is: ", i);
  return i;
}

When this:

function checkScope() 
{
"use strict";
let i = 'function scope';
if (true) 
{
  let i = 'block scope';
  console.log('Block scope i is: ', i);
}
console.log('Function scope i is: ', i);
return i;
}

is not correct.

As you can see, the system accepted an answer with double quotes and not with single quotes.

This was not explained anywhere throughout the course(unless I missed it) and as a result I believe the question needs to be clarified for future users.

freeCodeCamp.org

[snowmonkey]

Is the issue the single quotes, or is it the opening curly bracket on another line?

What you have right now says “if true… Then nothing. and as a separate block, do this stuff.”

In your context, single quotes, double quotes and backticks are the same. But as we can have a single-line if statement without curly braces, that’s what the javascript engine parses your code as doing. And we can have a curly-brace wrapped code block at any point, simply to group code, and that’s what the javascript engine thinks you want.

Move the opening curly brace to be beside your if clause, and it should be the same as the original.

[bbsmooth]

@snowmonkey

What you have right now says “if true… Then nothing. and as a separate block , do this stuff.”

Is this correct? I tested the code with the opening curly on the next line using node and it seemed to work fine. I personally always put the opening curly on the same line as the if statement but I swear I’ve seen it done the other way all the time.

[lasjorg]

The placement of the brackets for the if statement is purely formatting/style it has nothing to do with how the code is executed.

if (true)
{
  console.log('true'); // true
}

It does matter in other cases (ASI).

(() => {
  return
  {
    name: 'John'
  }
})();
// undefined

(() => {
  return {
    name: 'John'
  }
})();
// {name: 'John'}

https://2ality.com/2013/01/brace-styles.html

Indentation style

---

The test regex is the reason why it fails.

const code = `
function checkScope() 
{
"use strict";
let i = 'function scope';
if (true)
{
  let i = 'block scope';
  console.log('Block scope i is: ', i);
}
console.log('Function scope i is: ', i);
return i;
}
`

console.log(code.match(/(i\s*=\s*).*\s*.*\s*.*\1('|")block\s*scope\2/g)); // null

const code = `
function checkScope() 
{
"use strict";
let i = 'function scope';
if (true) {
  let i = 'block scope';
  console.log('Block scope i is: ', i);
}
console.log('Function scope i is: ', i);
return i;
}
`

console.log(code.match(/(i\s*=\s*).*\s*.*\s*.*\1('|")block\s*scope\2/g)); // [ 'i = \'function scope\';\nif (true) {\n  let i = \'block scope\'' ]

[triangle4studios]

If curly braces are sensitive, that should be one of the first things taught in the lessons. Did I miss it somewhere?
Because as far as I can tell they are logically the same thing.
Replacing quotes was the only thing I changed to make it work, and whats more, console outputs both reported correct results.

[bbsmooth]

@triangle4studios

If curly braces are sensitive, that should be one of the first things taught in the lessons. Did I miss it somewhere?

Reread @lasjorg last post again, placement of curly braces does not matter, this is an issue with the test.

[snowmonkey]

Well golly. I think my brain was auto piloting yesterday, i do apologize for that. Feel like a doofus now…

I honestly don’t think I’ve ever done curly braces on the next line like that, simply assumed it would break.

[lasjorg]

@snowmonkey No worries, we’ve all been there.

That indentation style is more common in other languages. I seem to remember the style (well some variant of it anyway) being enforced in the CS50 course, at least for C. I don’t think there are many if any, JS style guides that have that style of indentation as recommended. One of the reasons given is the ASI rules can conflict with it, like in the return example.

The indentation (or lack of) in the second code example makes it harder to read in my opinion. But that is often how it goes with an unfamiliar style, it messes with your pattern recognition.

Personally, I wouldn’t mind if the JS challenges enforced a style guide. Teaching good code formatting is just as important as syntax and logic.

[triangle4studios]

Reread @lasjorg last post again, placement of curly braces does not matter, this is an issue with the test.

@bbsmooth I read it like 10 times because I was sure quotes were the issue.
The link he posted clarifies that javascript has its own indentation style, of which, misuse can cause code to break.

Brace styles and JavaScript

From the post

For example:
return {
name: ‘Jane’
};
If you formatted that in Allman style, you’d have:
// Don’t do this
return
{
name: ‘Jane’
};
However, JavaScript’s automatic semicolon insertion [2] adds a semicolon after return, if it is followed by a newline. The above code is thus equivalent to
return;
{
name: ‘Jane’
};

[triangle4studios]

I honestly don’t think I’ve ever done curly braces on the next line like that, simply assumed it would break

In some languages, it is considered unprofessional not to use allman style. C# is an example of one such language.

Most companies who use c# require it. And I am sure other languages follow suit.

[lasjorg]

@triangle4studios If you are ever in doubt press Shift + Alt + F in the code editor. It should give you standard JS formatting.

It’s probably safer to stick with that style as a lot of challenges use regex to test the code and sometimes all it takes to break the tests are unexpected formatting. It shouldn’t break with valid syntax, but it can be harder than it sounds to account for all coding styles when writing the regex.

[triangle4studios]

Javascript needs to address this. It is very inconsistent. I dispise non-allman style formatting. I truely believe brackets should be in line with their opposites.
It aids in readability.

[lasjorg]

It is up to each person or team to enforce whatever style they prefer. But I can almost guarantee that you are not going to change the general consensus about whatever the currently most accepted style is, in whatever language.

There is really no way you can say there is a right or wrong style. If it was that simple there wouldn’t be so many different styles, to begin with. Even if some people have gone so far as to name some styles “the one true brace style” (K&R + variants) that is just hyperbole. There are also historical reasons, and language specific syntax reasons, why each language has its own set of style guides that do not agree with each other.

Two very popular and commonly used in JS are.

GitHub - airbnb/javascript: JavaScript Style Guide

What is Prettier? · Prettier

[JeremyLT]

Personally, I find brace style wars utterly uninteresting, like most other coding wars. The only thing I get evangelical about is inconsistency. I don’t ‘despise’ whatever style a project uses, so long as they are consistent and clear.

I don’t think I have had anyone go so far as to call another person’s whitespace and brace preferences ‘unprofessional’. The only thing that’s unprofessional is refusing to use the style guidelines for your current project. Each project gets to decide what ‘professional’ style means in their codebase.

All of the C-style languages, as far as I know, can use any of the main brace styles. You can write C# with Allman, K&R, 1TBS, Horstmann, GNU, or whatever you like. It really doesn’t matter. Same goes for C, C++, JavaScript, etc. There is nothing to ‘fix’. Whitespace does not have syntactic meaning in C-style languages on purpose. If you want whitespace to have meaning, look at other languages, like Python.

I personally prefer 1TBS. It seems to me be readable and not generate superfluous lines only for opening braces, and it seems to be the most common style I’ve run across. I’ve also worked in codebases that use Allman without complaint. It’s not my favorite, but it is fine. I just use the formatter to make sure that my code meets the standards of the project I’m working on.

[snowmonkey]

I’ve always followed Kernigan, but i imagine it’s what one picks up along the way. Most of my languages of choice have always been interpreted (or JIT-compiled, like javascript), and nearly always used the curly brace on the same line as it’s triggering clause.

I wonder if the preference thing follows compiled vs interpreted… But i suspect that most dev shops, is they don’t have one, soon develop or adopt a style guide.

[triangle4studios]

But as @lasjorg pointed out, Allman cannot be used in javascript when using regex. In that particular cirumstance, it is not preference, but syntax.

This is something that no one here has seemed to acknowledge yet. Which tells me that few people know this.

[JeremyLT]

That’s not what he said at all. You can use Allman just fine in JavaScript.

The freeCodeCamp test suite uses Regex to verify some solutions. Those Regex sometimes assume 1TBS since it is the most common style in JS.

In this challenge, that is a fair assumption, as it is very uncommon for users to completely rewrite portions of code unrelated to the task they have been given.

It isn’t that nobody is acknowledging some secret flaw you’ve discovered in JS. It’s that the flaw that you’re seeing does not exist.

[DanCouper]

There’s one specific place where adding a newline matters (directly after the keyword return), that’s it, and it’s extremely well known. The situation where it occurs in error isn’t common anyway, and it doesn’t have any affect on Allman style, which specifies putting the opening bracket of a block on a new line; the issue doesn’t occur with Allman style [edit: any more than with 1TBS] (you can’t return a block in JS, so the keyword will never appear before one in otherwise-valid code)