DEV Community

Andy Chen
Andy Chen

Posted on

Testbuilder comments v1

  1. wise choice of variable declarations!
  2. general rule of thumb is: if a value or a method/function is used 3. more than once with the same arguments, setting a variable for it may be a good idea
  3. instead of having JS constantly process a function call, we can process it once, save it in memory (a variable) and just use this data from memory for more efficiency ⚡

CONS -
Variable Naming
we should name variables very explicitly, like plain English.

  1. do not create numbered variables; avoid naming variables like x1, x2, x3 etc, even if the number has some meaning!
  2. consider using a name such as firstTwoDigits or firstTwoCharacters
  3. using a mathematical range detection approach would be a more efficient process ⚡
  4. instead of having JS process 5 separate conditions, we can speed things up by checking 2 conditions just remember to adhere to best practices and convert your string into a number
  5. we can shorten our code a LOT if we were to use native JS methods such as .includes/.indexOf that would address the work that we're doing within this entire loop~
  6. instead of this very "hard-coded" approach, consider using the card variables above with our detection

    if ( ( card === '38' || card === '39' ) && cardNumber.length === 14) {
    
    return "Diner's Club";
    

} ```

this type of approach would allow for us to address (1) network per if block which reduces the amount of repetitiveness

  1. we can create a library of helpers for each card network
    this type of work is a bit less on priority as it is our main duty to pump out a working product more than a perfect product
    the idea here is to build a library of "alike" functions that all do the same thing
    they all just want to confirm whether or not the card belongs to their network
    inside these helpers is where we want to use our other helpers to help with the detection

  2. JS's type coercion will always prioritize String data types
    therefore, there is no need to call .toString here

Top comments (0)