Username constraints are incomplete

Tell us what’s happening:
The challenge provides the following constraints for the userCheck regular expression to fit :
1. Usernames can only use alpha-numeric characters.
2. The only numbers in the username have to be at the end. There can be zero or more of them at the end.
3. Username letters can be lowercase and uppercase.
4. Usernames have to be at least two characters long. A two-character username can only use alphabet letters as characters.

These constraints do not require that the first character be alphabetic if the number of characters is greater than two. Therefore, userCheck should match “007”.

Your code so far


let username = "JackOfAllTrades";
let userCheck = /^[a-z][a-z]+\d*$|^[a-z]\d\d+$|^\d\d\d+$/i; // Change this line
let result = userCheck.test(username);

Your browser information:

User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36.

Challenge: Restrict Possible Usernames

Link to the challenge:
https://www.freecodecamp.org/learn/javascript-algorithms-and-data-structures/regular-expressions/restrict-possible-usernames

Thank you for helping make FCC better. Bugs can be reported as GitHub Issues. Whenever reporting a bug, please check first that there isn’t already an issue for it and provide as much detail as possible.

This is not a bug. This is a known mismatch between the definition of the challenge and a test procedure. There is no way to fix it without knowing the intent of the creator.

Hello, @djafferian.

I am struggling to see why the tests should match 007.

As you quoted, the tests say:

  1. The only numbers in the username have to be at the end. There can be zero or more of them at the end.
  1. Usernames have to be at least two characters long. A two-character username can only use alphabet letters as characters.

007 is three characters long. Therefore, may contain up to two numbers, because “The only numbers in the username have to be at the end”. The 0 at the start is not a number at “the end”.

Do you agree?

1 Like

A “mismatch between the definition of the challenge and a test procedure” is commonly called a bug :slight_smile:

@Sky020, I don’t think that I agree with you. For the proposed username 007, the numbers start after all letters. As I read it, if there are numbers and letters, all numbers must come after all letters. The block of letters is empty, so vacuously the block of numbers follows the block of letters. There is no requirement that a three+ character username must have any letters.

I do understand where you are coming from, but I think it all boils down to the fact that for:

const userName = 007;

userName[0] is not at the end of the variable, and is not a letter.

It is mentioned twice that “numbers… have to be at the end”.

I will see if others agree that the challenge needs to be rephrased, or not.

I think that “end” is linguistically imprecise here and I think it’s a bad way to sneak in an ambiguous/hidden requirement to have at least one letter.

If I saw a PR with the documentation
“The only numbers in the username have to be at the end.”
and it was supposed to mean
“There must be at least one letter in the username and the only numbers in the username have to come after all letters.”
I would require a documentation clarification before merging.

Most people intuit it, but just adding “Usernames must begin with a letter.” is an easy addition to the description that makes it more precise.

2 Likes

Those damn math guys… If you don’t tell us we must do X, we’ll spend 10x as much effort justifying why we technically don’t have to do X within the provided parameters :slight_smile:

2 Likes

I disagree. The 0 at the start IS a number at “the end”.

If ‘007’ is not matched then it must violate one or more of the four constraints. It satisfies constraints 1 and 3 and since it is three characters long, it does not violate constraint 4. So constraint 2 is the only one we need to examine.

A point of possible confusion is what is intended by the word ‘numbers’. In general (and in Javascript as well), a single ‘number’ can be represented by a sequence of one or more digits. But if this is the meaning in this context then we would have to agree that ‘007’ is a number which is not only at the start, but is at the end as well.

A more relevant point of confusion is what is meant by “at the end”. A single character is certainly “at the end” if it is the last character in the string. But if the last character is the only one which can be “at the end” then ‘Z97’ would not be a valid username. A substring of characters is certainly “at the end” of the string if it is not followed by any other characters, and constraint 2 assures that all of the “numbers” in the string must be contained in a substring which contains no other characters and is “at the end” of the string. Since a string is a substring of itself, so its characters are always both “at the end” and “at the start”. Therefore the numbers in the string ‘007’ are both “at the start” and “at the end”, and do not violate constraint 2.

Constraint 4 prevents the string ‘8’ from being a valid username. Suppose that constraint 4 was removed. Then would you insist that ‘8’ would still not be a valid username because the 8 was not “at the end” ?

Perhaps the constraint missing here is one that prevents the first character in a username from being a number. But I can’t assert this without knowing what was the creator’s intent.

If the software correctly implements the detailed design then there are no bugs. :upside_down_face:

The tests and the challenge are inconsistent. That means there is a bug. You created this thread because there is a bug in the description of the challenge compared to the tests…

Normally there are no bugs if tests are implemented correctly. Even if description is indeed uncertain, tests explicitly tell you “Should not match” and that should be your source of truth

Personally, I would say that tests and user requirements not clearly agreeing is a bug in either the tests or the user requirements.

If tests are implemented correctly then a failed test indicates a bug, but the success of a set of correctly implemented tests is no assurance that there are no bugs. In this case, the inconsistency between the challenge and one of its tests is not a bug because this inconsistency exists before any flawed software solution is produced.

The FCC curriculum is a software product. The inconsistency between the description and the tests in this challenge is a bug in FCC, which, again, is a software product. That is why you were given a link to flag a bug report in the FCC GitHub repo.

In the case of freecodecamp, failed tests indicate incomplete solution rather than bug in it’s software :smiley:
The problem with this solution is solely vague description and not the tests

This is just my opinion, but relying upon users to file bug reports is bad software management. Users complain. They are hardly ever equipped with enough knowledge to identify a defect, even if they have access to the code. Just because someone thinks that the software should work in a different way does not mean that there is a bug. Filing concise bug reports should be the responsibility of experienced support personnel who have a better understanding of the product as a whole.

Having users file bug reports is common practice in the open source world. A more experienced project maintainer may modify or close the issue, but it is the users that find the bugs… while they are using the software.

In theory FCC could hire a person to translate user bugs into formal bug reports, but they are working on a shoestring budget here. Refining user generated bug reports works just fine.

Also, the purpose of FCC is to teach people how to be web developers. Part of being a professional developer is learning how to file bug reports.

I disagree completely. Tests exist to validate the code against the detailed design, not the other way around. Given that “the intent was the first character should be a letter,” we can indeed assert that the “description” fails to meet this requirement, even before any code has been written, if we were astute enough to catch the mistake. And I assert that where there is no code, there are no bugs. Only once the description has been corrected can we ascertain whether a test failure is caused by an inadequate test or a defect in the product.