fixing-keyboard.js docs

[perminder-17]

No description provided.

[holomorfo]

I'm wondering if a select(key) would be better or will it cause confusion for some users? We could simplify the if else logic, what do you think?

[holomorfo]

// Update x and y if an arrow key is pressed.
if (keyIsPressed === true) {
  switch (keyCode) {
    case 38: // Up arrow key
      y -= 1;
      break;
    case 40: // Down arrow key
      y += 1;
      break;
    case 37: // Left arrow key
      x -= 1;
      break;
    case 39: // Right arrow key
      x += 1;
      break;
  }
}

[davepagurek]

I'm ok leaving this one as is for now since after a quick search, we don't use switch/case in other reference examples so far, so while it can be simplified, it might be a little easier to understand for now if we use the more familiar if/else` construct.

[holomorfo]

while this is correct and same from the old version, I think its a pattern we should discourage, maybe add a note at the begining that keyIsDown() returns true and false, and we don't need to explicitly compare with the truth value.

[ksen0]

I would support simplifying this as you suggest.

[davepagurek]

I generally also agree, but also wanted to flag that this is consistent with what the current documentation style guide has, so we might want to also update that if we're considering changing the pattern we want to use.

[perminder-17]

I believe it’s valuable to maintain the explicit comparison with === true because it ensures both clarity and consistency with our current style guide. By explicitly checking for the boolean true, we remove any ambiguity around type coercion, making the code more readable and easier to reason about, especially for newer contributors who might be less familiar with how JavaScript treats truthy and falsy values. Additionally, if the style guide specifically calls out this convention, it’s simpler and more consistent to uphold it in the code rather than change the guide itself. This keeps our documentation and code aligned without introducing extra work or confusion about whether keyIsDown is always guaranteed to return a strict boolean.

Currently we could keep this as it is and in future if it comes up, I would be more than happy to change the style-guide and replace by not comparing with truth values? Let me know your thoughts?

[davepagurek]

I think at this point it's ok to leave as-is because probably other things are priority if that's ok with everyone else. But maybe we can make an issue to discuss changing the style guide + updating other docs?